Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Падает производительность при поиске по ключу.
|
|||
|---|---|---|---|
|
#18+
Всем привет. Недавно столкнулся со странной штукой. Резкий рост времени выполнения запроса по одной определенной таблице и огромная нагрузка на CPU. Вы сейчас скажите, индексы проморгал, не тут-то было. По факту: 10.1.21-MariaDB Трафик 8 ГиБ/час Под БД выделяем ~200 Гб RAM 4xSSD 800Gb RAID 10 Размер БД 150 Гб Таблицы InnoDB Проблемная таблица: Размер: 20 Гб. и ~ 120 млн. строк (12 ГиБ данных и 9.2 ГиБ индекса) * на данный момент Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. Оптимизация не помогает. Чтобы исправить ситуацию приходится чистить таблицу(удалять данные в ущерб проекту), после чистки нагрузка спадает почти до нулевой. Причем ни кол-во запросов, ни трафик - не меняются, и даже на оборот, возрастают. (т.к. сервер начинает быстрее обрабатывать запросы) Скрин нагрузки на машину: http://joxi.ru/l2ZxW06t9kBQrJ Вешает MySQL вот этот безобидный запрос: Код: sql 1. Индекс пробовал менять вместо id_out_link, date_add на id_out_link . Безрезультатно. Что заметил, тем больше общий объем БД, тем чаще приходится чистить таблицу data_table . Не далек тот день, когда чистка этой таблицы уже не будет помогать и придется чистить всю БД На этом мои идеи кончились. Надеюсь вы мне поможете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2017, 11:58 |
|
||
|
Падает производительность при поиске по ключу.
|
|||
|---|---|---|---|
|
#18+
Код: sql 1. и Код: sql 1. у кого-то руки не там выросли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2017, 13:23 |
|
||
|
Падает производительность при поиске по ключу.
|
|||
|---|---|---|---|
|
#18+
Вы хотите указать мне на кавычки ? =) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2017, 15:41 |
|
||
|
Падает производительность при поиске по ключу.
|
|||
|---|---|---|---|
|
#18+
1) limit бtз Order By 2) explain? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2017, 16:45 |
|
||
|
Падает производительность при поиске по ключу.
|
|||
|---|---|---|---|
|
#18+
NitroGenerateВы хотите указать мне на кавычки ? =) я хочу сказать надо сравнивать int c int, а не с varchar ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2017, 18:11 |
|
||
|
Падает производительность при поиске по ключу.
|
|||
|---|---|---|---|
|
#18+
NitroGenerateПод БД выделяем ~200 Гб RAMА MySQL-ю об этом сказать не забыли? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2017, 20:12 |
|
||
|
Падает производительность при поиске по ключу.
|
|||
|---|---|---|---|
|
#18+
И, помимо кавычек, бесполезно сравнивать '4584858094' с полем типа int UNSIGNED, т.к. такое число туда даже не влезет. Подозреваю, что MySQL оба значения для корректного сравнения приводит к bigint и в результате этого индекс использовать становится невозможно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2017, 20:33 |
|
||
|
Падает производительность при поиске по ключу.
|
|||
|---|---|---|---|
|
#18+
miksoft, Вы вот щас серьезно про кавычки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2017, 21:02 |
|
||
|
Падает производительность при поиске по ключу.
|
|||
|---|---|---|---|
|
#18+
ScareCrowmiksoft, Вы вот щас серьезно про кавычки?Да, вполне. На форуме пару-тройку раз встречалась ситуация, когда MySQL преобразование типов производил в неверном направлении. Т.е. не строковый литерал в число, а числовое поле в строку. Поэтому считаю, что такой вариант исключать нельзя, хотя он и редок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2017, 21:27 |
|
||
|
|

start [/forum/topic.php?fid=47&fpage=77&tid=1830800]: |
0ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
25ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 245ms |
| total: | 370ms |

| 0 / 0 |
