Ускорение внутренних соединений между большим столом и маленьким столом
Как включить mysqli в php.ini
- Измените / раскомментировать, удалив ';' (двоеточие) следующую конфигурацию в php.ini: 1 (uncomment и add config): include_path = «C: \ php \ includes» 2nd (uncomment): extension_dir = «ext» 3rd (uncomment и edit config): extension = C: /PHP/ext/php_mysql.dll extension = C: /PHP/ext/php_mysqli.dll
- Перезапустить сервер IIS
- Убедитесь, что mysql запущен в системе.
Как загрузить файл php.ini
- Переименуйте любой из файлов php.ini-production / php.ini-development в php.ini из C: \ PHP (обратите внимание, что расширение будет ini, то есть «php.ini»).
- После переименования на сервер перезагрузки сервера php.ini
- См. изменения в http: //localhost/phpinfo.php
2 ответа
Нет, порядок не имеет значения.
Почти все СУБД (такие как MS Access, MySQL, SQL Server, ORACLE и т. Д.) Используют оптимизатор на основе стоимости, основанный на статистике столбцов. В большинстве случаев оптимизатор выберет правильный план.В приведенном вами примере порядок не имеет значения (при условии актуальной статистики).
Чтобы решить, какую стратегию запросов использовать, оптимизатор Jet Engine использует статистику . Следующие факторы являются некоторыми из факторов, на которых основана эта статистика:
- Количество записей в таблице
- Количество страниц данных в таблице
- расположение таблицы
- Наличие индексов
- Насколько уникальны индексы
Примечание : вы не можете просматривать схемы оптимизации ядра базы данных Jet, и вы не можете указать, как оптимизировать { {1}} запрос. Однако вы можете использовать средство документации базы данных, чтобы определить наличие индексов и его уникальность.
На основе этой статистики оптимизатор затем выбирает лучшую стратегию внутреннего запроса для обработки определенного запроса.
Статистика обновляется при компиляции запроса . Запрос помечается для компиляции, когда вы сохраняете любые изменения в запросе (или его базовых таблицах) и когда база данных сжимается. Если запрос помечен для компиляции, компиляция и обновление статистики происходит при следующем запуске запроса. Обычно компиляция занимает от одного запроса. секунды до четырех секунд.
Если вы добавляете в базу данных значительное количество записей , вы должны открыть и затем сохранить запросы, чтобы перекомпилировать запросы. Например, если вы разрабатываете, а затем тестируете запрос, используя небольшой набор образцов данных, вы должны повторно скомпилировать запрос после дополнительных записей добавляются в базу данных .При этом вы хотите, чтобы был уверен, что оптимальная производительность запроса достигается при использовании вашего приложения.
Ссылка .
Могут быть интересны: ACC: Как оптимизировать запросы в Microsoft Access 2.0, Microsoft Access 95 и Microsoft Access 97
Стоит прочитать Часто задаваемые вопросы о производительности Microsoft Access Тони Тьюза.
Я знаю, что Oracle нет в вашем списке, но я думаю, что большинство современных баз данных будут вести себя подобным образом.
Вы можете видеть в следующем плане выполнения, что нет никакой разницы между двумя утверждениями.
Это полный доступ к каждой из двух таблиц (без индекса в моем случае), а затем HASH JOIN. Поскольку вам нужно все из обеих таблиц, обе таблицы должны быть прочитаны и объединены, последовательность не имеет значения.
---------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
---------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 100 | 700 | 42 (12)| 00:00:01 |
|* 1 | HASH JOIN | | 100 | 700 | 42 (12)| 00:00:01 |
| 2 | TABLE ACCESS FULL| S | 100 | 300 | 2 (0)| 00:00:01 |
| 3 | TABLE ACCESS FULL| L | 100K| 390K| 38 (8)| 00:00:01 |
---------------------------------------------------------------------------