Как это не принимает? Конечно, принимает. Вы это можете заметить, например, в случае если у вас подобный запрос:
SELECT blah-blah FROM table WHERE col1 = x ORDER BY col2
При условии, что у вас есть два индекса по полям col1 и col2
MySQL будет принимать решение какой именно индекс в данном запросе «выгодней» использовать.
Ну сами данные изменились, и условия (Where) по которым проходила склейка таблиц.
Т.е. вначале получалось, что датасет из первой таблицы, после применения фильтров, был не очень большим (несколько сотен записей), поэтому было быстрей вначале подготовить этот датасет, отсортировать его и проводить INNER JOIN склейку.
Когда же этот датасет стал большим (десятки тысяч записей), то выгодней стало вначале подготовить второй датасет (по условию фильтров на второй таблице), и уже клеить к нему первую таблицу. И хоть сортировка в этом случае и была без индекса, но она происходила в памяти на гораздо меньшем числе записей (1-2 порядка).
не нужно переставлять таблицы. Нужно смотреть Explain, SHOW STATUS, PROFILING и делать выводы, что в вашем запросе не так. Может какой-то индекс не используется, может какой-то индекс нужно добавить. Может нужно изменить запрос — добавить derived table или другой трюк. Это в любом случае лучше чем FORCE INDEX или STRAIGHT_JOIN
Во-первых, запросы в таком виде (не отформатированные) очень сложно читать. Почему-то очень многие забывают что SQL запросы нужно также форматирвоать как и код.
Во-вторых, нужно осознавать, что STRAIGHT_JOIN это не серебрянная пуля, а хак. При котором, мы указывает MySQL оптимизатору в каком именно порядке нам нужно клеить таблицы. И если это работает сейчас, это совсем не означает, что это будет и дальше работать с приемлемой для нас скоростью.
Совсем недавно сталкивался с ситуацией, когда вот таким образом заставили определенные запросы на тестовом датасете работать быстро. А когда данные изменились запрос стал очень тормозить, т.к. для MySQL стало «невыгодно» фильровать и сортировать по первой таблице (датасет стал очень большим), и более выгодно было выполнить вначале фильтр по второй таблице в склейки, там где условия фильтров давали небольшой результирующий датасет, и уже клеить первую таблицу к нему.
Честно-говоря, не совсем понятно зачем этот sub-select вообще нужен, т.е. зачем усложнять запрос.
Когда два года назад решал эту же задачу на базе MaxMind, то обошелся
просто запросом:
SELECT * FROM ip2country WHERE `ipn1` <= INET_ATON('IP') ORDER BY `ipn1` DESC LIMIT 1
где индекс по полю `ipn1` будет использоваться как для фильтра, так и для сортировки.
Зачем вообще добавлять условие
WHERE `ipn2` >= INET_ATON('IP')
?
Мне так нравится, когда люди начинают на полном серьезе говорить откровенно очевидные вещи, правда.
Я только не понимаю почему в хабра-редактор до сих пор не добавили тег , потому что без него становится изъясняться все тяжелее. Особенно когда речь касается php.
Нужно также оценить инженерную мысль. Люди используют для безопасности аж 2 гет параметра с хэшами
&code=U1lLRVRATUFJTC5SVQ==&hash=2e9b91e1ee0949585c784942bc1e0339
чтобы никто лишний не попал на эту страницу!
Глобально и надежно! Только из-за этого сложного инженерного решения можно сказать, что сайт на PHP написан
SELECT blah-blah FROM table WHERE col1 = x ORDER BY col2
При условии, что у вас есть два индекса по полям col1 и col2
MySQL будет принимать решение какой именно индекс в данном запросе «выгодней» использовать.
Т.е. вначале получалось, что датасет из первой таблицы, после применения фильтров, был не очень большим (несколько сотен записей), поэтому было быстрей вначале подготовить этот датасет, отсортировать его и проводить INNER JOIN склейку.
Когда же этот датасет стал большим (десятки тысяч записей), то выгодней стало вначале подготовить второй датасет (по условию фильтров на второй таблице), и уже клеить к нему первую таблицу. И хоть сортировка в этом случае и была без индекса, но она происходила в памяти на гораздо меньшем числе записей (1-2 порядка).
Когда я читал статью у меня сложилось впечатление, что автор сбросил кеш перезапуском MySQL :-)
Во-вторых, нужно осознавать, что STRAIGHT_JOIN это не серебрянная пуля, а хак. При котором, мы указывает MySQL оптимизатору в каком именно порядке нам нужно клеить таблицы. И если это работает сейчас, это совсем не означает, что это будет и дальше работать с приемлемой для нас скоростью.
Совсем недавно сталкивался с ситуацией, когда вот таким образом заставили определенные запросы на тестовом датасете работать быстро. А когда данные изменились запрос стал очень тормозить, т.к. для MySQL стало «невыгодно» фильровать и сортировать по первой таблице (датасет стал очень большим), и более выгодно было выполнить вначале фильтр по второй таблице в склейки, там где условия фильтров давали небольшой результирующий датасет, и уже клеить первую таблицу к нему.
Когда два года назад решал эту же задачу на базе MaxMind, то обошелся
просто запросом:
SELECT * FROM ip2country WHERE `ipn1` <= INET_ATON('IP') ORDER BY `ipn1` DESC LIMIT 1
где индекс по полю `ipn1` будет использоваться как для фильтра, так и для сортировки.
Зачем вообще добавлять условие
WHERE `ipn2` >= INET_ATON('IP')
?
Я только не понимаю почему в хабра-редактор до сих пор не добавили тег , потому что без него становится изъясняться все тяжелее. Особенно когда речь касается php.
А чем эти ссылки хуже других с точки зрения поисковика? только потому, что на них нет других внутренних ссылок на сайте?
www.youtube.com/watch?v=8kmUjJlNr88
&code=U1lLRVRATUFJTC5SVQ==&hash=2e9b91e1ee0949585c784942bc1e0339
чтобы никто лишний не попал на эту страницу!
Глобально и надежно! Только из-за этого сложного инженерного решения можно сказать, что сайт на PHP написан
Просто люди не прописали robots.txt и не закрыли там нужный раздел от роботов.
Зато пользуются Яндекс Метрикой. И она честно добавляет все известные ей страницы в индекс.
Вот и получилось, что у Гугла этих страниц в индексе нет, т.к. на них нигде нет ссылок. А у Яндекса благодаря Метрике есть