javajdbcкстати, у меня возникла непонятная идея:
а что если придумать синтакс выборке по индексу.
Точнее разрешить (с некими ограничениями) использовать
имя индекса в FROM секции
Это будет функционально совпадать с случаем
Using index в Ехтра секции Експлейна.пофантазирую тоже малость, попредметнее:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
SELECT
table3.ct1, table3.ct5, table3.ct3, table3.ct2
,Sum(table2.ct3) AS wct3
,Sum(table2.ct4) AS bct4
,CEIL(Avg(table2.ct6)) AS bact6
FROM KEY Table1.IX_ct4_ct1 t1 -- (покрывающий) индекс на Table1 (ct4,ct1)
JOIN table2 ON table2.ct1 = t1.ct1
JOIN table3 ON table3.ct4 = table2.ct2 AND table3.ct5 = 6
WHERE t1.ct4 > 3424 AND t1.ct4 < 3624
GROUP BY table2. ct2, table3. ct1, table3.ct5
ORDER BY bact6 DESC
И какой в этом смысл? Индекс создаем сами, явно его указываем в запросе вместо таблицы (чтобы добиться в Extra строки Using index)
При этом мы выполняем (теоретически) вместо компилятора анализ статистики и навязываем своё вИдение оптимального выполнения запроса.
Так ведь и сейчас никто не запрещает использовать для этого
FROM table1 t1 USE KEY(IX_ct4_ct1) .
Прямой выгоды 0, ятд, потому как при наличии индекса компилятор и сам в состоянии построить оптимальный план выполнения.
Другое дело, если бы сервер подсказал, что для более оптимального выполнения запроса с учетом имеющейся статистики было бы неплохо построить вот такой индекс, дал бы его описание, ну, и оценил бы в процентах повышение эффективности обработки с учетом нового индекса.
MS SQL это умеет, MySQL - хз...
