Я отвечаю на свой вопрос дополнительными данными, которые я собрал на основе ваших ответов.
Я использовал два ноутбука, подключенных через беспроводную сеть.На ноутбуке A я смонтировал каталог ноутбука B, используя sshfs.Затем на ноутбуке AI запустил MySQL, указав этот смонтированный каталог в качестве своего каталога данных.Это должно обеспечить MySQL очень медленным устройством ввода-вывода.MySQL был запущен с innodb_flush_log_at_trx_commit = 0.
. Я определил 3 набора запросов, каждый из которых состоял из обновления и запроса выбора, повторенного 10000 раз, без явных транзакций.Эксперименты были:
- US1SID: обновить и выбрать в определенной строке той же таблицы.Во всех итерациях использовалась одна и та же строка.
- US1MID: обновить и выбрать конкретную строку в той же таблице.Строка была разной на каждой итерации.
- US2MID: обновлять и выбирать строки разных таблиц.В этом случае таблица, читаемая селектором, вообще не изменилась во время эксперимента.
Каждый набор запускался дважды с использованием сценария оболочки (следовательно, время было медленнее, чем в моем исходном вопросе), одна в нормальных условиях, а другая после выполнения следующей команды:
tc qdisc replace dev wlan0 root handle 1:0 netem delay 200ms
Приведенная выше команда добавляет среднюю задержку в 200 мс при передаче пакетов через wlan0.
Во-первых, вот среднеевремя наибольших 99% самых быстрых обновлений и выборок, а нижних 1% обновляет и выбирает.
| Delay: 0ms | Delay: 200ms |
| US1SID | US1MID | US2MID | US1SID | US1MID | US2MID |
| top99%u | 0.0064 | 0.0064 | 0.0064 | 0.0063 | 0.0063 | 0.0063 |
| top99%s | 0.0062 | 0.0063 | 0.0063 | 0.0062 | 0.0062 | 0.0062 |
| bot01%u | 1.1834 | 1.2239 | 0.9561 | 1.9461 | 1.7492 | 1.9731 |
| bot01%s | 0.4600 | 0.5391 | 0.3417 | 1.4424 | 1.1557 | 1.6426 |
Как видно, даже при очень низкой производительности ввода-вывода MySQL удается выполнять большинство запросов.действительно быстро.Но больше всего меня беспокоит наихудший случай, так что вот еще одна таблица, показывающая 10 самых медленных запросов.«U» означает, что это было обновление, а «s» - выбор.
| Delay: 0ms | Delay: 200ms |
| US1SID | US1MID | US2MID | US1SID | US1MID | US2MID |
| 5.443 u | 5.946 u | 5.315 u | 11.500 u | 10.860 u | 11.424 s |
| 5.581 u | 5.954 s | 5.466 u | 11.649 s | 10.995 u | 11.496 s |
| 5.863 s | 6.291 u | 5.658 u | 12.551 s | 11.020 u | 12.221 s |
| 6.192 u | 6.513 u | 5.685 u | 12.893 s | 11.370 s | 12.599 u |
| 6.560 u | 6.521 u | 5.736 u | 13.526 u | 11.387 u | 12.803 u |
| 6.562 u | 6.555 u | 5.743 u | 13.997 s | 11.497 u | 12.920 u |
| 6.872 u | 6.575 u | 5.869 u | 14.662 u | 12.825 u | 13.625 u |
| 6.887 u | 7.908 u | 5.996 u | 19.953 u | 12.860 u | 13.828 s |
| 6.937 u | 8.100 u | 6.330 u | 20.623 u | 14.015 u | 16.292 u |
| 8.665 u | 8.298 u | 6.893 u | 27.102 u | 22.042 s | 17.131 u |
Выводы:
Плохая производительность ввода-вывода может действительно замедлить MySQL доползать.Непонятно , почему или , когда точно, но это случается.
Замедление применяется как к выборкам, так и к обновлениям, с обновлениями, страдающимиподробнее.
По какой-то причине даже операции выбора в таблице, которые не были вовлечены в какие-либо изменения и которые недавно были заполнены, также были замедлены, как видно из US2MID выше.
Что касается тестовых примеров, предложенных mentatkgs, кажется, что обновление разных строк вместо одних помогает немного, но не решает проблему.
Думаю, я либо адаптирую свое программное обеспечение, чтобы терпеть такие задержки, либо попытаюсь перейти к другому провайдеру.Аренда выделенного сервера слишком дорогая для этого проекта.
Спасибо всем за комментарии.