|
|
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
список команд для партишенов REORGANIZE PARTITION ANALYZE PARTITION CHECK PARTITION OPTIMIZE PARTITION REBUILD PARTITION REPAIR PARTITION ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 08:48:18 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
Уже было, оптимизация на InnoDB - это просто пересоздание файла. В данном случае таблица только создана и она ничего не даст... Поправьте если не так. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 08:58:01 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
Aleksandr KuzminskyHett, А зачем Вам вообще partitions? Это уже другой вопрос :) Вообще проблема была в том, что на большой таблице стали "виснуть" INSERT запросы в статусе USER LOCK (хотя никто никаких локов никто не делал и вообще подозреваю что это был какой-то баг) и откуда ноги росли не могли понять, каждый раз спасались упрощением триггера, выкидывали из него какие-то проверки и вуаля, все снова работало какое-то время. После нескольких случаев решили попробовать партишены, в общем-то все теперь работает с полными триггерами. Вот только по производительности вопрос) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 09:00:05 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
Hett, Запусти partition explane select...., покажи результат ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 13:31:35 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
Да он тут по сути просто добавляет информацию о затронутых партишенах, как я понял SIMPLEfh_user_filep0,p1,p2,p3,p4,p5,p6,p7,p8,p9,p10,p11,p12,p13,p14,p15,p16,p17,p18,p19,p20,p21,p22,p23,p24index(null)IX_user_file_abuse_status1(null)7913957Using index ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 13:39:36 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
HettДык я же говорю, я и не ждал ускорения и прекрасно понимал, что будет работать медленнее, но не в 10 раз же. Но вообще, если уж так подумать, то мог бы и быстрее, если бы он каждую партицию считал в другом потоке параллельно. Это я уже выше все писал, вы у меня уже по второму кругу одни и те же вопросы спрашиваете и кто тут читает кого, а кто кого нет, - вопрос еще спорный :) Щас потестил на версии 5.6 под виндой, хоть 10 партиций, хоть 100, время одно, 5 секунд. На убунте в версии 5.5 почему-то 10 партишенов работали медленее чем 25. Запрос Код: sql 1. 2. 3. На продакшене запрос выполнялся раньше за 0.1 секунды, теперь 1.1 секунды. Да и вообще любые группирующие запросы в общем так себя проявили. Тот же Код: sql 1. Первый запрос может выиграть при патрицировании по user_id. Второй -- нет, при любом партицировании. Я ещё раз тебя призываю опубликовать DDL твоей таблицы и реальный запрос, один, с которым "проблемы". Тут у тебя user_id, там у тебя id... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 13:54:30 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
Вот запрос написал как есть, только ошибся в имени таблицы, все остальное так же слово в слово (+ алиасы). Проблемы не с ним одним, елки палки, а со всем аггрегирующими запросами. Есть индекс из одного поля user_id, партицирование Код: sql 1. 2. 3. 4. 5. 6. 7. уже писалось в первом запросе. Сейчас случайно обнаружил, что на виндовой тачке, где мускуль 5.6 и работало все чуть быстрее (чем на линнуксе где мускуль 5.5), что innodb_buffer_pool_size совсем маленький, поставил больше, запрос стал выполняться 1.5 секунды (собстна тут и ясно, почему 4кк записей "летали". а 7 стали тупить). Но вот на линуксовой тачке стоит буфер 32 гига сейчас, и запрос как тупил так и тупи, у меня уже складывается подозрение что это проблема мускуля 5.5, sort_buffer тоже ничего не дает. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 14:25:51 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
Причем на версии 5.6 хоть 100 партиций, хоть 25, скорость одна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 14:34:41 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
HettЭто уже другой вопрос :) Вообще проблема была в том, что на большой таблице стали "виснуть" INSERT запросы в статусе USER LOCK (хотя никто никаких локов никто не делал и вообще подозреваю что это был какой-то баг) и откуда ноги росли не могли понять, каждый раз спасались упрощением триггера, выкидывали из него какие-то проверки и вуаля, все снова работало какое-то время. После нескольких случаев решили попробовать партишены, в общем-то все теперь работает с полными триггерами. Вот только по производительности вопрос) Как-то необычно Вы подходите к решению задач. У Вас была проблема с локами, но вместо того, чтобы найти что держит этот лок, который не дает INSERT-у, Вы пробуете решения наугад. Это прямо как в анекдоте про кур и раввина - куры все сдохли, а идей еще было много. :-) Partitions решают очень узкий круг задач, и если Вы четко не видите, что Вам даст разбиение большой таблицы на несколько маленьких, то лучше не стоит разбивать. Очень легко нажить себе новых проблем, на что Вы и наткнулись судя по EXPLAIN. Мой Вам совет - вернитесь к началу, посмотрите, какие будут проблемы. Если опять вылезут блокировки, то соберите SHOW INNODB STATUS и присылайте сюда - будем изучать и делать выводы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 18:56:55 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
Hett, Member Откуда: Бийск, Новосибирск Сообщений: 10554 Вот запрос написал как есть, только ошибся в имени таблицы, все остальное так же слово в слово (+ алиасы). Проблемы не с ним одним, елки палки, а со всем аггрегирующими запросами. мужик, ты пойми, проблем с запросами "в общем" не бывает, они все конкретные, с конкретным запросом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 19:04:47 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
Aleksandr Kuzminsky, смотрели уже 100 спецов, все руками разводят. Просто работало все год, никто ничего не трогал, потом начались проблемы, каждый раз причину найти никто не мог, только нашли способ проблему отложить - упрощали триггер. А триггер в инсере особо ничего не делал, проверял другую табличку селектом и ставил флаг, таких запроса было 3 в триггере. Каждый раз по одному выкидывали и все снова работало. Это был не DEADLOCK а USER LOCK, откуда ему взяться, я же там SELECT FOR UPDATE и т.п. вещи не делал ведь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 20:32:20 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
MasterZivмужик, ты пойми, проблем с запросами "в общем" не бывает, они все конкретные, с конкретным запросом. Ну вот конкретно с SELECT COUNT(*) FROM tablname проблема, прям вот конкретно с ним. Я еще другой конкретный вопрос сюда выкладывал. Я понимаю был бы там запрос очень сложный, который юзал хитрые индексы и т.п., но тут просто негде ошибиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 20:34:04 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
HettПросто работало все год, никто ничего не трогал, потом начались проблемы, каждый раз причину найти никто не мог, только нашли способ проблему отложить - упрощали триггер. Вот и я о том же. Причину не нашли, зато придумали "решение". Прэлестно :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 20:37:20 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
Это решение позволило нам кроме всего прочего избавиться от постоянных DELETE запросов, которые фрагментировали таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 20:40:41 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
Aleksandr KuzminskyПричину не нашли, зато придумали "решение". Прэлестно :-) Вы, в общем-то тоже сейчас так поступили, не нашли решение данному вопросу, начали искать причины того, что мне это не надо ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 20:58:01 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
HettВы, в общем-то тоже сейчас так поступили, не нашли решение данному вопросу, начали искать причины того, что мне это не надо ;) Таблица 7 миллионов записей, размер базы тоже небольшой. Я очень сомневаюсь, что Вам нужны partitions. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2014, 21:57:48 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
автораблица 7 миллионов записей, размер базы тоже небольшой. Я очень сомневаюсь, что Вам нужны partitions. авторЭто решение позволило нам кроме всего прочего избавиться от постоянных DELETE запросов, которые фрагментировали таблицу. + проблема стриггерами, которую так и не понял никто. Вообще у меня уже создается впечатление, что это баг, но скомпроментировать его в ручную его не удается. Хотя, если честно, не сильно и пытались. По сабжу, поставили на линух мусколь 5.6 (правда перкону), запросы стали работать адекватно (чуть медленее чем без партишенов, но не существенно) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2014, 10:00:40 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
Короче судя по всему это проблема какая-то версии 5.5, т.к. в обычном мускуле 5.6 тоже все хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2014, 10:01:23 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
Hettсоздается впечатление, что это баг, но скомпроментировать его в ручную его не удается. Хотя, если честно, не сильно и пытались. У вас это постоянно происходит. Все темы такие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2014, 12:19:25 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
netwindHettсоздается впечатление, что это баг, но скомпроментировать его в ручную его не удается. Хотя, если честно, не сильно и пытались. У вас это постоянно происходит. Все темы такие. Дык все темы по этому поводу и были ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2014, 12:44:13 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
Hettnetwindпропущено... У вас это постоянно происходит. Все темы такие. Дык все темы по этому поводу и были Ну так надо же пытаться выделить "баг". Во время этого процесса вы полностью разберетесь как что работает и почти наверняка выяснится, что это и не баг вовсе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2014, 17:32:00 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
HettНу вот конкретно с автор SELECT COUNT(*) FROM tablname проблема, прям вот конкретно с ним. Ну вот и скажи, как этот запрос может убыстриться от наличия партиций на таблице tablname ? Как замедлиться -- я тебе уже объяснил. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 01:26:13 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
HettЭто решение позволило нам кроме всего прочего избавиться от постоянных DELETE запросов, которые фрагментировали таблицу. чего делали ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 01:27:00 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
MasterZivHettНу вот конкретно с пропущено... проблема, прям вот конкретно с ним. Ну вот и скажи, как этот запрос может убыстриться от наличия партиций на таблице tablname ? Как замедлиться -- я тебе уже объяснил. Так это он не привел полный запрос. Там еще дополнительные where были, ограничивающие по СЕКЦИЯМ. Проблема ТС в том, что он никогда не пытается собрать полную предварительную информацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 01:34:43 |
|
||
|
Partitioning again..
|
|||
|---|---|---|---|
|
#18+
netwindMasterZivпропущено... Ну вот и скажи, как этот запрос может убыстриться от наличия партиций на таблице tablname ? Как замедлиться -- я тебе уже объяснил. Так это он не привел полный запрос. Там еще дополнительные where были, ограничивающие по СЕКЦИЯМ. Проблема ТС в том, что он никогда не пытается собрать полную предварительную информацию. Ну так и я о том же. Сегодня у него так таблица называется, завтра эдак. Сегодня поле id, завтра user_id. ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2014, 01:48:05 |
|
||
|
|

start [/forum/topic.php?fid=47&msg=38557751&tid=1835225]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
49ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 356ms |

| 0 / 0 |
