Трассировка оптимизатора для разработчиков

В этой статье описаны рекомендации по написанию данных для трассировки оптимизатора при разработке сервера.

Основные соображения

Трассировка — это «структурированный журнал» действий оптимизатора. Предпочтительнее выполнять трассировку сразу после переработки/принятия решения (а не использовать отдельную функцию trace_something()).

(TODO другие соображения)

Обеспечение валидности трассировки

Классы Json_writer_object и Json_writer_array используют idiom RAII и гарантируют, что JSON-объекты и массивы «закрываются» в обратном порядке их создания.

Однако они не гарантируют следующие ограничения:

• JSON-объекты должны иметь именованные члены.
• JSON-массивы должны иметь безымянные члены.

Код трассировки содержит проверки на время выполнения для этих ограничений. Попытка записать невалидный JSON приведет к ошибке проверки.

Покрытие тестами

Можно запустить mysql-test-run с этим аргументом

 --mysqld=--optimizer_trace=enabled=on

Это запустит все тесты с включенной трассировкой. Как упоминалось ранее, сборка в режиме отладки проверит, что мы не генерируем невалидную трассировку.

Инстанция BuildBot по адресу http://buildbot.askmonty.org/ также запускает тесты с этим аргументом, см. mtr_opttrace для прохождения kvm-fulltest и kvm-fulltest2.

Отладка

В новых версиях MariaDB есть

const char *dbug_print_opt_trace();

функцию, которую можно использовать для вывода произведённой до этого момента трассировки.