Чуть подрихтовал отчет по 2-й омашке

test/dz002/REPORT.md

@@ -19,6 +19,7 @@
    WHERE users.Name LIKE "ан%" AND users.Surname LIKE "ан%"
    ORDER BY id
    ```
+![mountains](img/explain1.jpg "Explain запроса с прямым индексом")
 ### 3. В случае использования индекса indSurnameName:
    - #### Запрос на добавление индексов:
    ```
@@ -38,5 +39,6 @@
    WHERE users.Name LIKE "ан%" AND users.Surname LIKE "ан%"
    ORDER BY id
    ```
+![mountains](img/explain2.jpg "Explain запроса с обратным индексом")
 #### 4. РезюмеЖ
 Для конечной оптимизации используется составной индекс `('Surname', 'Name')` потому, что в запросе используется объединение AND условий LIKE ?%. Mysql в этом случае ищет по составному индексу и объединяет строки без сортировки. Именно поэтому, приходится принудительно сортировать результаты. Порядок полей выбран с точки зрения селективности. В реальной обстановке поле «Фамилия» все же более селективно чем «Имя». Плюс к этому, мы видим в EXPLAIN запроса, что в случае использования индекса `('Surname', 'Name')` mysql применяет Multi-Range Read оптимизацию, позволяющую линеаризовать процедуру чтения с диска. Возможно за этот счет значительно повысилась скорость передачи данных? по сравнению с индексом `('Name', 'Surname')`. 

test/dz003/REPORT.md

@@ -104,7 +104,7 @@ binlog_do_db = app
     ```
     APP_DSN_SLAVE1: mysql_slave1
     ```
-- #### Перезапускаем контейнер с приложением (в моем случае, перезапускаются и базу, но для данного эксперимента это не принципиально) и нагружаем ту же страницу тем же запросом, с помощью wrk:
+- #### Перезапускаем контейнер с приложением и нагружаем ту же страницу тем же запросом, с помощью wrk:
     ```
     sudo make app-reload
     sudo docker run --rm -v /root/scripts:/scripts williamyeh/wrk -t1 -c10 -d5m --timeout 30s http://localhost:8080/search -s /scripts/post.lua -- debug true