Откуда вы знаете, что запросы MySQL являются доминирующим фактором в проблемах производительности вашего сайта? Как ты это измерил?
Возможно, вам нужен другой дизайн.
Например, если вы выполняете запрос при каждом обновлении страницы, возможно, вы могли бы использовать memcache и обнаруживать случаи, когда обновление вызывает один и тот же запрос для повторения. Затем вы можете вернуть кэшированные результаты (возможно, при асинхронной проверке, чтобы выяснить, не требуют ли какие-либо промежуточные обновления внутренних баз данных аннулирование и / или обновление кэша).
Подумайте, как часто данные меняются и как часто они читаются. В некоторых случаях вы можете дополнить свой дизайн дополнительной таблицей, в которой публикуются метки времени обновления или номера генерации / серийные номера. Оттуда ваш механизм запросов может заменить сложный запрос, возможно, объединениями и требовать полного сканирования таблиц проверкой согласованности кэша, включающей простой запрос одного столбца в одной таблице. Если предыдущий запрос возвратил все автомобили, которые у вас были в базе данных 10 минут назад, и ни одна строка не была обновлена, вставлена или удалена из этих базовых таблиц или представлений, вы можете пропустить запрос и обратиться к кэшированным результатам.
Возможно, вы могли бы, чтобы ваш средний уровень (уровни) выполнял нечеткие запросы, а затем выводил данные на более точное подмножество перед представлением.
Например, веб-интерфейсный запрос для автомобилей по заданной цене в заданном регионе может быть переведен в стандартизированный запрос к базе данных для более широкого диапазона цен в более крупном регионе, при этом сервер приложений кэширует результаты, а затем фильтрует это до более конкретного подмножества, соответствующего этому веб-запросу. Другой аналогичный запрос затем может быть переведен в тот же стандартный абстрактный запрос ... и, таким образом, приложение может использовать кэшированные результаты, чтобы избежать обращения к внутренней БД.
Другими словами, когда вы спрашиваете об оптимизации ваших запросов, вам также следует спросить, есть ли у вас способы генерировать действительные, правильные результаты при выполнении меньшего количества запросов. Лучше уменьшить конкуренцию за узкое место, чем затратить значительные усилия на настройку потока через это узкое место.
На самом деле вам даже следует задаться вопросом, все ли эти данные принадлежат базе данных MySQL или некоторые из них лучше распределить по некоторому NoSQL (couchDB или Hadoop HBase и т. Д.). Базы данных SQL лучше всего использовать для транзакционных операций, которые налагают требования к ссылочной целостности на работу. Везде, где возможно, вы должны искать способы отделения тех операций, которые выполняются чаще и с большими объемами данных.