|
Как интерпретировать вывод EXPLAIN SELECT...
|
|||
---|---|---|---|
#18+
Как интерпретировать вывод EXPLAIN SELECT... Который выводит табличку со столбцами addr, opcode, p1, p2, p3, p4, p5, comment и десятком строк. Нигде не нашел описание того что означают данные в ней. Знаю что существует EXPLAIN QUERY PLAN , про него нашел только что если пишет USING INDEX это хорошо, а если USING COVERING INDEX то вообще радоваться нужно, все данные есть в индексе. Больше ничего и не пишет. Но на практике оказывается что этот EXPLAIN QUERY PLAN погоду на марсе показывает. Делаю выборку по двум полям. Текст и булево. выбираю весть текст где булево например фальш. Таблица 5,5 млн записей. Без индексов - 6,5 сек, с индексом "текст, булево" - 2,2 сек. А вот с индексом "булево,текст" - миллисекунды. Но и в том и в другом случае EXPLAIN QUERY PLAN пишет одно и тоже. USING COVERING INDEX... А вот данные в табличке по простому EXPLAIN разнятся. Может они более информативны, но как их понять? ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2020, 17:02 |
|
Как интерпретировать вывод EXPLAIN SELECT...
|
|||
---|---|---|---|
#18+
iskatelsql, Описание столбцов есть в родной документации https://www.sqlite.org/eqp.html sqliteeach node of the tree consists of four fields: An integer node id, an integer parent id, an auxiliary integer field that is not currently used, and a description of the node id - уникальный идентификатор parent - указывает на родительский элемент (т.к. план выводится в виде дерева) notused - не используется detail - комментарий iskatelsqlесли USING COVERING INDEX то вообще радоваться нужно, все данные есть в индексе Вот насколько я понял из доки, это не значит что всё ещё лучше, чем просто USING INDEX. Покрывающий индекс задействован в том случае, когда при выполнении запроса с отбором по некоему столбцу, для которого не существует индекса, но существует такой составной индекс (который в своём составе имеет это самое поле для отбора), тогда вместо полного сканирования таблицы, выполняется сканирования этого составного индекса. Поэтому мы за одну операцию не всегда можем найти нужную нам строку данных, т.к. при составном индексе задействованы ещё другие поля и наши данные для отбора могут оказаться где-то "дальше". Т.е. в виде примера, данные выглядят так: type = {1, 2, 3} param = {1 ... 1000} ещё поля... Создаём составной индекс Код: sql 1.
выполняем запрос Код: sql 1.
Будем пробегаться по всем строкам с type = 2, они есть в индексе и далее применяем второе условие отбора. Количество прочитанных строк будет столько, сколько type = 2 содержится в таблице. Итого, для конкретно ваших данных надо уже предметно смотреть. Возможно для конкретной задачи лучше создать индекс который будет идентифицировать однозначно строку, чтобы снизить количество физических чтений ... |
|||
:
Нравится:
Не нравится:
|
|||
05.09.2020, 21:51 |
|
Как интерпретировать вывод EXPLAIN SELECT...
|
|||
---|---|---|---|
#18+
iskatelsql Делаю выборку по двум полям. Текст и булево. выбираю весть текст где булево например фальш. Таблица 5,5 млн записей. Без индексов - 6,5 сек, с индексом "текст, булево" - 2,2 сек. А вот с индексом "булево,текст" - миллисекунды. Логично всё. Для выборки "булево = фальш" требуется полный скан индекса "текст, булево", индекс поменьше места занимает чем таблица, потому побыстрее немного получается чем просто скан таблицы. А индекс "булево,текст" позволяет читать только нужные записи, поэтому гораздо быстрее, но и то подозреваю что немного записей с "булево = фальш" ... |
|||
:
Нравится:
Не нравится:
|
|||
06.09.2020, 20:38 |
|
|
start [/forum/topic.php?fid=54&msg=39996027&tid=2008353]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
32ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 245ms |
total: | 374ms |
0 / 0 |