Какова Ваша наиболее распространенная sql оптимизация?

Пара подсказок: Используйте

delete from table where id>=1 and id<=3;

вместо

delete from table where id=1;
delete from table where id=2;
delete from table where id=3;

Также используйте 'IN' вместо синтаксиса 'OR'

Избегайте использования встроенных функций, таких как convertdate, stringreplace и т.п., в ваших представлениях. Если вы не можете убедиться, что данные находятся в допустимом формате, используйте хранимые процедуры, которые запускаются регулярно «очищать» данные в соответствующих таблицах.

это неприятно, но это экономит время просмотра, то есть делает пользователя счастливым ... ^^

1. индексирует наиболее распространенную оптимизацию
2. Де нормализация таблиц.
3. Удаление ограничений (только если вы знаете, что делаете)

Самые большие оптимизации, которые я использовал в последнее время, довольно просты.

Сохраняйте как можно большую часть бизнес-логики как можно ближе к серверу sql. Кроме того, ваш бизнес-код должен находиться на том же компьютере, что и сервер sql. Позвольте вашей бизнес-логике возвращать как можно меньше кода обратно конечному клиенту.

Делайте ваш SQL-запрос как можно короче, как сказал Фрост, используйте отдельные операторы обновления вместо нескольких операторов.

Используйте транзакции только тогда, когда вам нужно их

Создавайте временные таблицы для частичных объединений, чтобы ускорить их (не забудьте проиндексировать их)

Я прочитал все ответы и не нашел подсказок по использованию LIMIT и OFFSET. Это очень распространенное использование при разбивке на страницы с помощью ссылок «назад» и «далее». Но рендеринг такого отображения может потреблять больше ресурсов, чем весь остальной сайт. При смещении большого количества элементов запрос может стать очень медленным. Так что избегайте этих запросов.

• Не подсчитывайте общее количество элементов.
• Показывать только «n» первых элементов (например, только 100 лучших).

Такие методы используются Google, Twitter и другими сайтами. В поиске Google нет точного количества результатов. Есть только приблизительное количество. Twitter не позволяет пользователю просматривать все прошлые твиты. Он показывает только последнее число n (я не могу вспомнить, сколько).

Есть некоторая ссылка из блога производительности MySQL .

Убедитесь, что таблицы соединяются в правильном порядке.

Две самые важные вещи в по моему опыту меньше соединений и меньше запросов. Помимо этого, существует множество специфичных для БД вещей, COUNT (*) относительно медленен на PgSQL, подзапросы на MySQL очень медленны и т.д.

Лучшая оптимизация, которую я когда-либо использовал с помощью SQL, заключалась в том, чтобы действительно понять, что нужно сделать для обработки данных и УДАЛИТЬ тонны SQL из запроса.

Самый быстрый запрос - это запрос это не обязательно должно быть запущено.

ДЕЙСТВИТЕЛЬНО ДУМАЙТЕ о том, что вы делаете с данными. Вы работаете по порядку? (затем используйте код на основе набора).

• Вам действительно нужно присоединиться ко всем этим таблицам?

• Могут ли два небольших (простых) запроса работать лучше и быстрее, чем один большой запрос?

• Если вы объедините эти два запроса в один запрос, можно он работает быстрее?

Наконец, ПРОФИЛИРУЙТЕ ваши запросы (EXPLAIN PLAN или SQL PROFILER) и посмотрите на «IO получает». Обычно вы хотите уменьшить количество GET до отношения примерно 10, получаемого на одну строку вывода.

Снижение уровней изоляции транзакций для обхода блокировок таблиц для пользовательских запросов. Не всегда, но для отображения общей информации с помощью графического интерфейса он отлично работает.

1) Мне еще не удалось найти ситуацию, когда

SELECT Field1, Field2, (SELECT Count(*) FROM tblLinked WHERE tblLinked.Field3 = tblSource.Field3) AS TheTotal
FROM tblSource

не улучшается с помощью ЛЕВОГО СОЕДИНЕНИЯ с производной таблицей.

SELECT Field1, Field2, IsNull(Linked.TheTotal,0) AS TheTotal
FROM tblSource
LEFT JOIN (SELECT Field3, Count(*) AS TheTotal
    FROM tblLinked
    GROUP BY Field3) AS Linked ON tblSource.Field3 = Linked.Field3

2) Не сортируйте результаты по сервер, если приложение-потребитель не может сделать это само. Это менее часто применяется к веб-приложениям, но для настольных приложений клиентский ПК обычно имеет достаточно мощности и может с радостью выполнять сортировку.

3) Используйте EXISTS вместо проверки количества совпадающих записей.

4) Дон Не зацикливайтесь на выполнении запроса в одном предложении SELECT. Разумное использование табличных переменных (а иногда и временных таблиц) может значительно сократить количество обрабатываемых строк.

Индексируйте внешние ключи!

Возможно, это не оптимизация синтаксиса SQL-запросов, а скорее оптимизация хранилища. Но я все время вижу, как это происходит снова, и это раздражает.

Кэширование вывода базы данных. Избегать давления на базу данных вообще кажется разумной оптимизацией.

+1 memcached.

Безусловно и выше: Создание покрывающих индексов

Покрывающий индекс включает в себя все столбцы, которые потребуются запросу, тем самым избегая необходимости выполнять поиск по результатам поиска по индексу. Это позволит избежать ощущения системы, что сканирование может быть более быстрым (что замечательно быстро, учитывая стоимость поиска).

Но также стоит упомянуть:

Наличие индекса, позволяющего объединение слиянием. Объединение MERGE может происходить при объединении двух таблиц, упорядоченных по условиям объединения. Но, конечно же, говоря «таблица», мы действительно имеем в виду «индекс», верно ...

Также - удаление скалярных функций и использование вместо них функций с табличным значением ... поскольку скалярные функции не могут быть упрощены.

Также - добавление уникального индекса в столбец, который, как вы знаете, является уникальным, позволяя оптимизатору запросов использовать эти знания, чтобы сделать лучший выбор оптимизации. Также применяется к ограничениям NOT NULL.

Также - использование двоичной сортировки при сравнении строк, которые относятся к известному регистру, чтобы системе не приходилось рассматривать различные варианты регистра.

Конечно, я мог бы продолжить все. день ...

Роб

Если вы проектируете объекты, которые все являются поведением без состояния или все состояния и без поведения. Я думаю, что где-то в вашем дизайне есть изъян. На самом деле нечасто можно встретить такие объекты в реальном мире, и если это не дополнительные объекты, которые вы описываете, а представления объектов реального мира, тогда я думаю, что где-то что-то не так.

У меня нет любое заданное соотношение для состояния / поведения. Я думаю, что каждый объект принимает свою собственную форму, и это может значительно отличаться между объектами. Но я думаю, что со временем, и если вы много работаете над объектом, глаголы будут иметь тенденцию быть больше, чем существительные / прилагательные, то есть поведение будет доминировать в состоянии.

Это '

Если вы говорите о простом как об обычном, тогда Индексы - первое, что приходит мне в голову.

Это мощная техника, которую часто неправильно понимают и довольно часто злоупотребляют.

Затем я бы применил денормализацию, которая может немного повысить производительность для многих баз данных.

Оптимизация запросов - третья, и она тоже очень помогает. В наши дни я использую MySQL, и ведение журнала запросов очень помогает для оптимизации.

Memcached определенно не является распространенным явлением, хотя какое-то кеширование является частью многих веб-сайтов на стороне сценария (ASP.Net или PHP).