Partitioning again.. / MySQL

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

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

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / MySQL [игнор отключен] [закрыт для гостей] / Partitioning again..

57 сообщений из 57, показаны все 3 страниц

все

Partitioning again..

#38551737

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Есть таблица, записей 7кк

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

CREATE TABLE user_file (
  id char(13) NOT NULL
  ....
  PRIMARY KEY (id),
  ....
)
PARTITION BY KEY (`id`)
(
    PARTITION p0 ENGINE = INNODB,
    PARTITION p1 ENGINE = INNODB,
    ....
    PARTITION p24 ENGINE = INNODB
)

Запрос COUNT(*) без партиционирования выполняется 0.7 секунд, с 25 партициями = 10 секунд.
Вопрос собстна в том, почему так долго и можно ли что покрутить, чтобы хоть как-то улучшить время?
PS^ По сути проблема со всеми запросами которые аггрегируются, не то чтобы они совсем плохо работает, но вот где данных надо посчитать мало, выполняются очень быстро, но если много, то все, может какого буфера не хватает...

...

Рейтинг:

0 / 0

06.02.2014, 13:08:22

| Ответить | Цитировать | Написать

Partitioning again..

#38551755

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Гмм, причем на линуксовом сервере версии 5.5.34 эти 10 секунд.
На другом виндовом 5.6.14 за 1.2 секунды выполняется. Правда тут записей меньше (5кк здесь)

...

Рейтинг:

0 / 0

06.02.2014, 13:16:30

| Ответить | Цитировать | Написать

Partitioning again..

#38551763

miksoft

Участник

Сообщения: 36 746

Рейтинг: 0 / 0

Hettможет какого буфера не хватаетМожет, innodb_buffer_pool_size не хватает...

...

Рейтинг:

0 / 0

06.02.2014, 13:21:03

| Ответить | Цитировать | Написать

Partitioning again..

#38551781

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

На серверах стоит 12G на линуксе, на виндовом (где гораздо быстрее работает) - 4G

...

Рейтинг:

0 / 0

06.02.2014, 13:30:45

| Ответить | Цитировать | Написать

Partitioning again..

#38551783

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Сейчас скачаю на виндовый полную табличку в 7кк и сравню

...

Рейтинг:

0 / 0

06.02.2014, 13:31:11

| Ответить | Цитировать | Написать

Partitioning again..

#38551786

miksoft

Участник

Сообщения: 36 746

Рейтинг: 0 / 0

Повторное время такое же большое?
В плане запроса что-нибудь интересное есть?

...

Рейтинг:

0 / 0

06.02.2014, 13:31:56

| Ответить | Цитировать | Написать

Partitioning again..

#38551794

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Да повторное примерно такое же, раз по 5-10 запускл, ничего не меняется.

SIMPLEfh_user_fileindex(null)IX_user_file_abuse_status1(null)7476871Using index

Он похоже просто берет самый маленький индекс

Код: sql

1.
2.

 abuse_status tinyint(4) NOT NULL DEFAULT 0,
INDEX IX_user_file_abuse_status (abuse_status),

Вот с виндового:

SIMPLEfh_user_fileindex(null)IX_user_file_abuse_status1(null)5202505Using index

...

Рейтинг:

0 / 0

06.02.2014, 13:36:53

| Ответить | Цитировать | Написать

Partitioning again..

#38551799

miksoft

Участник

Сообщения: 36 746

Рейтинг: 0 / 0

HettОн похоже просто берет самый маленький индексПравильно, оно так и должно быть.

Попробуйте выполнить OPTIMIZE TABLE для это таблицы?
innodb_file_per_table, надеюсь, включена была до создания этой таблицы?

...

Рейтинг:

0 / 0

06.02.2014, 13:40:26

| Ответить | Цитировать | Написать

Partitioning again..

#38551805

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

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

...

Рейтинг:

0 / 0

06.02.2014, 13:48:14

| Ответить | Цитировать | Написать

Partitioning again..

#38551814

miksoft

Участник

Сообщения: 36 746

Рейтинг: 0 / 0

В запросе точно только COUNT(*), без ничего больше?

...

Рейтинг:

0 / 0

06.02.2014, 13:50:54

| Ответить | Цитировать | Написать

Partitioning again..

#38551835

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Код: sql

1.
2.

  SELECT COUNT(*) 
    FROM fh_user_file

Да, вот

...

Рейтинг:

0 / 0

06.02.2014, 14:04:01

| Ответить | Цитировать | Написать

Partitioning again..

#38551844

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Ну COUNT() это как простейший пример, вообще проблем с любым аггрегирующим запросом.

...

Рейтинг:

0 / 0

06.02.2014, 14:07:04

| Ответить | Цитировать | Написать

Partitioning again..

#38552963

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Залил на виндовый 7.5кк записей, запрос на каунт стал выполняться 5 секунд.
Сейчас буду пробовать на работу с 10 партишенами (было 25)

...

Рейтинг:

0 / 0

07.02.2014, 11:18:35

| Ответить | Цитировать | Написать

Partitioning again..

#38553385

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Чудеса
С 10 партишенами время выполнения 7 секунд, с 25 - 5
Если данных чуть меньше (4.5кк), то 1 секунда.

...

Рейтинг:

0 / 0

07.02.2014, 14:06:19

| Ответить | Цитировать | Написать

Partitioning again..

#38554272

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Hett,

видишь ли, дорогой виртуальный друг, то, как работает запрос немного зависит от того, что это за запрос. Чуть менее чем полностью. Поэтому вопрошать так без полного текста запроса и полного DDL не то что глупо, а попросту бессмысленно.

...

Рейтинг:

0 / 0

08.02.2014, 06:06:47

| Ответить | Цитировать | Написать

Partitioning again..

#38554273

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Hett

Код: sql

1.
2.

  SELECT COUNT(*) 
    FROM fh_user_file

Да, вот

такой запрос бессмысленен и оптимизировать его так же мало смысла.

...

Рейтинг:

0 / 0

08.02.2014, 06:09:44

| Ответить | Цитировать | Написать

Partitioning again..

#38554275

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Hett

Код: sql

1.
2.

  SELECT COUNT(*) 
    FROM fh_user_file

...

Рейтинг:

0 / 0

08.02.2014, 06:15:59

| Ответить | Цитировать | Написать

Partitioning again..

#38554315

miksoft

Участник

Сообщения: 36 746

Рейтинг: 0 / 0

MasterZivон должен наоборот замедляться, в твоем конкретно случае примерно в 25 разПочему?

...

Рейтинг:

0 / 0

08.02.2014, 11:01:06

| Ответить | Цитировать | Написать

Partitioning again..

#38554317

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

MasterZivHett

Код: sql

1.
2.

  SELECT COUNT(*) 
    FROM fh_user_file

Да, вот

и еще. с чего ты взял что такой запрос должен ускоряется после партицирования? он должен наоборот замедляться, в твоем конкретно случае примерно в 25 раз, чуть менее. твои времена примерно такой картине и соответствуют.

Почему он должен замедляться в 25 раз? В таком случае можно сказать что любые аггрегирующие запросы будут замедляться в n-раз.
Тогда за одно может и поведуете, почему в случае с 10 партишенами скорость еще хуже чем с 25-ю?
Чем, в данном случае поможет DDL?

автортакой запрос бессмысленен и оптимизировать его так же мало смысла.
Как я выше уже писал, стали заметно хуже выполняться все аггрегирующие запросы, проблема в них.

автори еще. с чего ты взял что такой запрос должен ускоряется после партицирования?
Вообще, теоретически если предположить, он может ускоряться хотя бы за счет того, что запросы к каждому партишену параллелятся (именно такое слово употреблено в официальной документации). Но ладно, но на это я и не рассчитывал, в общем-то, пусть даже медленее, но не в 25 раз же...

...

Рейтинг:

0 / 0

08.02.2014, 11:05:46

| Ответить | Цитировать | Написать

Partitioning again..

#38554780

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Hett,

потому что запрос вида

SELECT COUNT(*)
FROM user_file

обрабатывает все партиции, а не одну.
Их у тебя 25. Будет соотв. в 25 раз больше.
Плюс накладуха на сборку общего результата из частных по каждой партиции (думаю, не очень большая).

Другое дело, что скан всего в одной таблице и 1/25-ой всего в одной партиции -- тоже разные вещи.
Но по крайней мере спуск в дереве таблиц точно в 25 раз будет помножен.

В любом случае, не понятоно с чего бы такому запросу ускорится от наличия партицый

...

Рейтинг:

0 / 0

09.02.2014, 01:59:38

| Ответить | Цитировать | Написать

Partitioning again..

#38554820

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

MasterZivИх у тебя 25. Будет соотв. в 25 раз больше.
А ниче, что партиции в 25 раз меньше?

...

Рейтинг:

0 / 0

09.02.2014, 07:39:41

| Ответить | Цитировать | Написать

Partitioning again..

#38555185

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

HettMasterZivИх у тебя 25. Будет соотв. в 25 раз больше.
А ниче, что партиции в 25 раз меньше?

ты вообще читаешь что я пишу?

еще раз, за счет чего по твоему запрос должен вдруг заработать быстрее после разбиения на партиции?

кстати, запрос дай.

...

Рейтинг:

0 / 0

10.02.2014, 02:06:10

| Ответить | Цитировать | Написать

Partitioning again..

#38556147

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Дык я же говорю, я и не ждал ускорения и прекрасно понимал, что будет работать медленнее, но не в 10 раз же. Но вообще, если уж так подумать, то мог бы и быстрее, если бы он каждую партицию считал в другом потоке параллельно. Это я уже выше все писал, вы у меня уже по второму кругу одни и те же вопросы спрашиваете и кто тут читает кого, а кто кого нет, - вопрос еще спорный :)
Щас потестил на версии 5.6 под виндой, хоть 10 партиций, хоть 100, время одно, 5 секунд. На убунте в версии 5.5 почему-то 10 партишенов работали медленее чем 25.

Запрос

Код: sql

1.
2.
3.

SEELCT COUNT(*), SUM(size)
FROM user
WHERE user_id = :user_id

На продакшене запрос выполнялся раньше за 0.1 секунды, теперь 1.1 секунды. Да и вообще любые группирующие запросы в общем так себя проявили. Тот же

Код: sql

SELECT COUNT(*) FROM tablename

...

Рейтинг:

0 / 0

10.02.2014, 18:16:09

| Ответить | Цитировать | Написать

Partitioning again..

#38556316

Aleksandr Kuzminsky

Гость

Hett,

А зачем Вам вообще partitions?

...

Рейтинг:

0 / 0

10.02.2014, 21:11:29

| Ответить | Цитировать | Написать

Partitioning again..

#38556618

многоразовый клон 26

Участник

Сообщения: 3 408

Рейтинг: 0 / 0

miksoftHettОн похоже просто берет самый маленький индексПравильно, оно так и должно быть.

Попробуйте выполнить OPTIMIZE TABLE для это таблицы?
innodb_file_per_table, надеюсь, включена была до создания этой таблицы?

насколько я знаю, надо делать OPTIMIZE PARTITION

...

Рейтинг:

0 / 0

11.02.2014, 08:47:48

| Ответить | Цитировать | Написать

Partitioning again..

#38556619

многоразовый клон 26

Участник

Сообщения: 3 408

Рейтинг: 0 / 0

список команд для партишенов

REORGANIZE PARTITION
ANALYZE PARTITION
CHECK PARTITION
OPTIMIZE PARTITION
REBUILD PARTITION
REPAIR PARTITION

...

Рейтинг:

0 / 0

11.02.2014, 08:48:18

| Ответить | Цитировать | Написать

Partitioning again..

#38556629

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Уже было, оптимизация на InnoDB - это просто пересоздание файла. В данном случае таблица только создана и она ничего не даст... Поправьте если не так.

...

Рейтинг:

0 / 0

11.02.2014, 08:58:01

| Ответить | Цитировать | Написать

Partitioning again..

#38556632

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Aleksandr KuzminskyHett,

А зачем Вам вообще partitions?
Это уже другой вопрос :)
Вообще проблема была в том, что на большой таблице стали "виснуть" INSERT запросы в статусе USER LOCK (хотя никто никаких локов никто не делал и вообще подозреваю что это был какой-то баг) и откуда ноги росли не могли понять, каждый раз спасались упрощением триггера, выкидывали из него какие-то проверки и вуаля, все снова работало какое-то время. После нескольких случаев решили попробовать партишены, в общем-то все теперь работает с полными триггерами. Вот только по производительности вопрос)

...

Рейтинг:

0 / 0

11.02.2014, 09:00:05

| Ответить | Цитировать | Написать

Partitioning again..

#38557019

многоразовый клон 26

Участник

Сообщения: 3 408

Рейтинг: 0 / 0

Hett,

Запусти partition explane select...., покажи результат

...

Рейтинг:

0 / 0

11.02.2014, 13:31:35

| Ответить | Цитировать | Написать

Partitioning again..

#38557031

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Да он тут по сути просто добавляет информацию о затронутых партишенах, как я понял

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

...

Рейтинг:

0 / 0

11.02.2014, 13:39:36

| Ответить | Цитировать | Написать

Partitioning again..

#38557068

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

HettДык я же говорю, я и не ждал ускорения и прекрасно понимал, что будет работать медленнее, но не в 10 раз же. Но вообще, если уж так подумать, то мог бы и быстрее, если бы он каждую партицию считал в другом потоке параллельно. Это я уже выше все писал, вы у меня уже по второму кругу одни и те же вопросы спрашиваете и кто тут читает кого, а кто кого нет, - вопрос еще спорный :)
Щас потестил на версии 5.6 под виндой, хоть 10 партиций, хоть 100, время одно, 5 секунд. На убунте в версии 5.5 почему-то 10 партишенов работали медленее чем 25.

Запрос

Код: sql

1.
2.
3.

SEELCT COUNT(*), SUM(size)
FROM user
WHERE user_id = :user_id

Код: sql

SELECT COUNT(*) FROM tablename

Первый запрос может выиграть при патрицировании по user_id. Второй -- нет, при любом партицировании.

Я ещё раз тебя призываю опубликовать DDL твоей таблицы и реальный запрос, один, с которым "проблемы".
Тут у тебя user_id, там у тебя id...

...

Рейтинг:

0 / 0

11.02.2014, 13:54:30

| Ответить | Цитировать | Написать

Partitioning again..

#38557136

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Вот запрос написал как есть, только ошибся в имени таблицы, все остальное так же слово в слово (+ алиасы). Проблемы не с ним одним, елки палки, а со всем аггрегирующими запросами.

Есть индекс из одного поля user_id, партицирование

Код: sql

1.
2.
3.
4.
5.
6.
7.

PARTITION BY KEY (`id`)
(
    PARTITION p0 ENGINE = INNODB,
    PARTITION p1 ENGINE = INNODB,
    ....
    PARTITION p24 ENGINE = INNODB
)

уже писалось в первом запросе.

Сейчас случайно обнаружил, что на виндовой тачке, где мускуль 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.

innodb_flush_log_at_trx_commit  = 2
max_sp_recursion_depth          = 255
group_concat_max_len            = 4294967295
table_cache                     = 4096
innodb_buffer_pool_size         = 32G
innodb_log_buffer_size          = 16M
innodb_file_per_table           = true
innodb_io_capacity              = 20000
innodb_write_io_threads         = 32
innodb_read_io_threads          = 32
transaction-isolation           = READ-COMMITTED
sort_buffer_size                = 256M
thread_concurrency              = 48

...

Рейтинг:

0 / 0

11.02.2014, 14:25:51

| Ответить | Цитировать | Написать

Partitioning again..

#38557153

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Причем на версии 5.6 хоть 100 партиций, хоть 25, скорость одна.

...

Рейтинг:

0 / 0

11.02.2014, 14:34:41

| Ответить | Цитировать | Написать

Partitioning again..

#38557590

Aleksandr Kuzminsky

Гость

HettЭто уже другой вопрос :)
Вообще проблема была в том, что на большой таблице стали "виснуть" INSERT запросы в статусе USER LOCK (хотя никто никаких локов никто не делал и вообще подозреваю что это был какой-то баг) и откуда ноги росли не могли понять, каждый раз спасались упрощением триггера, выкидывали из него какие-то проверки и вуаля, все снова работало какое-то время. После нескольких случаев решили попробовать партишены, в общем-то все теперь работает с полными триггерами. Вот только по производительности вопрос)

Как-то необычно Вы подходите к решению задач.
У Вас была проблема с локами, но вместо того, чтобы найти что держит этот лок, который не дает INSERT-у, Вы пробуете решения наугад. Это прямо как в анекдоте про кур и раввина - куры все сдохли, а идей еще было много. :-)
Partitions решают очень узкий круг задач, и если Вы четко не видите, что Вам даст разбиение большой таблицы на несколько маленьких, то лучше не стоит разбивать. Очень легко нажить себе новых проблем, на что Вы и наткнулись судя по EXPLAIN.

Мой Вам совет - вернитесь к началу, посмотрите, какие будут проблемы. Если опять вылезут блокировки, то соберите SHOW INNODB STATUS и присылайте сюда - будем изучать и делать выводы.

...

Рейтинг:

0 / 0

11.02.2014, 18:56:55

| Ответить | Цитировать | Написать

Partitioning again..

#38557602

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Hett,

Member

Откуда: Бийск, Новосибирск
Сообщений: 10554 Вот запрос написал как есть, только ошибся в имени таблицы, все остальное так же слово в слово (+ алиасы). Проблемы не с ним одним, елки палки, а со всем аггрегирующими запросами.

мужик, ты пойми, проблем с запросами "в общем" не бывает, они все конкретные, с конкретным запросом.

...

Рейтинг:

0 / 0

11.02.2014, 19:04:47

| Ответить | Цитировать | Написать

Partitioning again..

#38557714

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Aleksandr Kuzminsky,

смотрели уже 100 спецов, все руками разводят.
Просто работало все год, никто ничего не трогал, потом начались проблемы, каждый раз причину найти никто не мог, только нашли способ проблему отложить - упрощали триггер. А триггер в инсере особо ничего не делал, проверял другую табличку селектом и ставил флаг, таких запроса было 3 в триггере. Каждый раз по одному выкидывали и все снова работало. Это был не DEADLOCK а USER LOCK, откуда ему взяться, я же там SELECT FOR UPDATE и т.п. вещи не делал ведь.

...

Рейтинг:

0 / 0

11.02.2014, 20:32:20

| Ответить | Цитировать | Написать

Partitioning again..

#38557716

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

MasterZivмужик, ты пойми, проблем с запросами "в общем" не бывает, они все конкретные, с конкретным запросом.

Ну вот конкретно с SELECT COUNT(*) FROM tablname проблема, прям вот конкретно с ним. Я еще другой конкретный вопрос сюда выкладывал. Я понимаю был бы там запрос очень сложный, который юзал хитрые индексы и т.п., но тут просто негде ошибиться.

...

Рейтинг:

0 / 0

11.02.2014, 20:34:04

| Ответить | Цитировать | Написать

Partitioning again..

#38557722

Aleksandr Kuzminsky

Гость

HettПросто работало все год, никто ничего не трогал, потом начались проблемы, каждый раз причину найти никто не мог, только нашли способ проблему отложить - упрощали триггер.

Вот и я о том же. Причину не нашли, зато придумали "решение". Прэлестно :-)

...

Рейтинг:

0 / 0

11.02.2014, 20:37:20

| Ответить | Цитировать | Написать

Partitioning again..

#38557731

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Это решение позволило нам кроме всего прочего избавиться от постоянных DELETE запросов, которые фрагментировали таблицу.

...

Рейтинг:

0 / 0

11.02.2014, 20:40:41

| Ответить | Цитировать | Написать

Partitioning again..

#38557751

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Aleksandr KuzminskyПричину не нашли, зато придумали "решение". Прэлестно :-)
Вы, в общем-то тоже сейчас так поступили, не нашли решение данному вопросу, начали искать причины того, что мне это не надо ;)

...

Рейтинг:

0 / 0

11.02.2014, 20:58:01

| Ответить | Цитировать | Написать

Partitioning again..

#38557817

Aleksandr Kuzminsky

Гость

HettВы, в общем-то тоже сейчас так поступили, не нашли решение данному вопросу, начали искать причины того, что мне это не надо ;)

Таблица 7 миллионов записей, размер базы тоже небольшой. Я очень сомневаюсь, что Вам нужны partitions.

...

Рейтинг:

0 / 0

11.02.2014, 21:57:48

| Ответить | Цитировать | Написать

Partitioning again..

#38558084

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

автораблица 7 миллионов записей, размер базы тоже небольшой. Я очень сомневаюсь, что Вам нужны partitions.

авторЭто решение позволило нам кроме всего прочего избавиться от постоянных DELETE запросов, которые фрагментировали таблицу.

+ проблема стриггерами, которую так и не понял никто.

Вообще у меня уже создается впечатление, что это баг, но скомпроментировать его в ручную его не удается. Хотя, если честно, не сильно и пытались.

По сабжу, поставили на линух мусколь 5.6 (правда перкону), запросы стали работать адекватно (чуть медленее чем без партишенов, но не существенно)

...

Рейтинг:

0 / 0

12.02.2014, 10:00:40

| Ответить | Цитировать | Написать

Partitioning again..

#38558085

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Короче судя по всему это проблема какая-то версии 5.5, т.к. в обычном мускуле 5.6 тоже все хорошо.

...

Рейтинг:

0 / 0

12.02.2014, 10:01:23

| Ответить | Цитировать | Написать

Partitioning again..

#38558289

netwind

Участник

Сообщения: 14 195

Рейтинг: 0 / 0

Hettсоздается впечатление, что это баг, но скомпроментировать его в ручную его не удается. Хотя, если честно, не сильно и пытались.

У вас это постоянно происходит. Все темы такие.

...

Рейтинг:

0 / 0

12.02.2014, 12:19:25

| Ответить | Цитировать | Написать

Partitioning again..

#38558335

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

netwindHettсоздается впечатление, что это баг, но скомпроментировать его в ручную его не удается. Хотя, если честно, не сильно и пытались.

У вас это постоянно происходит. Все темы такие.

Дык все темы по этому поводу и были

...

Рейтинг:

0 / 0

12.02.2014, 12:44:13

| Ответить | Цитировать | Написать

Partitioning again..

#38558853

netwind

Участник

Сообщения: 14 195

Рейтинг: 0 / 0

Hettnetwindпропущено...

У вас это постоянно происходит. Все темы такие.

Дык все темы по этому поводу и были
Ну так надо же пытаться выделить "баг". Во время этого процесса вы полностью разберетесь как что работает и почти наверняка выяснится, что это и не баг вовсе.

...

Рейтинг:

0 / 0

12.02.2014, 17:32:00

| Ответить | Цитировать | Написать

Partitioning again..

#38559220

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

HettНу вот конкретно с

автор SELECT COUNT(*) FROM tablname

проблема, прям вот конкретно с ним.

Ну вот и скажи, как этот запрос может убыстриться от наличия партиций на таблице tablname ?
Как замедлиться -- я тебе уже объяснил.

...

Рейтинг:

0 / 0

13.02.2014, 01:26:13

| Ответить | Цитировать | Написать

Partitioning again..

#38559221

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

HettЭто решение позволило нам кроме всего прочего избавиться от постоянных DELETE запросов, которые фрагментировали таблицу.

чего делали ?

...

Рейтинг:

0 / 0

13.02.2014, 01:27:00

| Ответить | Цитировать | Написать

Partitioning again..

#38559223

netwind

Участник

Сообщения: 14 195

Рейтинг: 0 / 0

MasterZivHettНу вот конкретно с

пропущено...

проблема, прям вот конкретно с ним.

Ну вот и скажи, как этот запрос может убыстриться от наличия партиций на таблице tablname ?
Как замедлиться -- я тебе уже объяснил.

Так это он не привел полный запрос. Там еще дополнительные where были, ограничивающие по СЕКЦИЯМ.
Проблема ТС в том, что он никогда не пытается собрать полную предварительную информацию.

...

Рейтинг:

0 / 0

13.02.2014, 01:34:43

| Ответить | Цитировать | Написать

Partitioning again..

#38559225

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

netwindMasterZivпропущено...

Ну вот и скажи, как этот запрос может убыстриться от наличия партиций на таблице tablname ?
Как замедлиться -- я тебе уже объяснил.

Так это он не привел полный запрос. Там еще дополнительные where были, ограничивающие по СЕКЦИЯМ.
Проблема ТС в том, что он никогда не пытается собрать полную предварительную информацию.

Ну так и я о том же.
Сегодня у него так таблица называется, завтра эдак.
Сегодня поле id, завтра user_id.
...

...

Рейтинг:

0 / 0

13.02.2014, 01:48:05

| Ответить | Цитировать | Написать

Partitioning again..

#38559518

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

MasterZivHettНу вот конкретно с

пропущено...

проблема, прям вот конкретно с ним.

Ну вот и скажи, как этот запрос может убыстриться от наличия партиций на таблице tablname ?
Как замедлиться -- я тебе уже объяснил.

Вы мне третий раз уже этот вопрос задаете. Я 2 раза уже ответил. Думаю третий раз уже не стоит.

...

Рейтинг:

0 / 0

13.02.2014, 11:07:45

| Ответить | Цитировать | Написать

Partitioning again..

#38559520

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

MasterZivHettЭто решение позволило нам кроме всего прочего избавиться от постоянных DELETE запросов, которые фрагментировали таблицу.

чего делали ?

https://www.google.ru/search?q=mysql fragmented tables&oq=mysql fragmented tables&aqs=chrome..69i57j0l5.233j0j7&sourceid=chrome&espv=210&es_sm=93&ie=UTF-8

...

Рейтинг:

0 / 0

13.02.2014, 11:08:48

| Ответить | Цитировать | Написать

Partitioning again..

#38559524

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

netwindMasterZivпропущено...

Ну вот и скажи, как этот запрос может убыстриться от наличия партиций на таблице tablname ?
Как замедлиться -- я тебе уже объяснил.

Так это он не привел полный запрос. Там еще дополнительные where были, ограничивающие по СЕКЦИЯМ.
Проблема ТС в том, что он никогда не пытается собрать полную предварительную информацию.

Откуда вы взяли эту информацию? Из другой темы? Там был совсем другой запрос и таблица.

...

Рейтинг:

0 / 0

13.02.2014, 11:09:25

| Ответить | Цитировать | Написать

Partitioning again..

#38559570

netwind

Участник

Сообщения: 14 195

Рейтинг: 0 / 0

Hettnetwindпропущено...

Так это он не привел полный запрос. Там еще дополнительные where были, ограничивающие по СЕКЦИЯМ.
Проблема ТС в том, что он никогда не пытается собрать полную предварительную информацию.

Откуда вы взяли эту информацию? Из другой темы? Там был совсем другой запрос и таблица.
домыслил. как-то же он должен был ускорять

...

Рейтинг:

0 / 0

13.02.2014, 11:33:09

| Ответить | Цитировать | Написать

Partitioning again..

#38559586

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

Я первом же посте написал ддл таблицы, на секции бьются по HASH(id) :)

...

Рейтинг:

0 / 0

13.02.2014, 11:44:48

| Ответить | Цитировать | Написать

Partitioning again..

#38559758

netwind

Участник

Сообщения: 14 195

Рейтинг: 0 / 0

Hett, так это означает что партиции вообще никак ничего не ускоряют в первом приближении. Приходится согласиться со всем о чем MasterZiv написал .
Какие-то другие эффекты и настройки могли что-то изменить, но с позиции оптимизатора SQL работы меньше не стало.

...

Рейтинг:

0 / 0

13.02.2014, 13:32:30

| Ответить | Цитировать | Написать

Partitioning again..

#38559790

Hett

Участник

Откуда: Бийск, Новосибирск

Сообщения: 13 075

Рейтинг: 0 / 0

netwindHett, так это означает что партиции вообще никак ничего не ускоряют в первом приближении. Приходится согласиться со всем о чем MasterZiv написал .
Какие-то другие эффекты и настройки могли что-то изменить, но с позиции оптимизатора SQL работы меньше не стало.

Да я понимаю, как уже и говорил, ускорения и не ждал. но 10 кратное замедление (не зависящее от количества партиций) насторожило просто, подумалось может какого буфера не хватает, поэтому на форуме тему и создал. Как показали "опыты", в 5.6 такой проблемы нет, мы решили перейти на продакшене на версию 5.6, и проблема в общем-то отпала. Возможно просто в 5.5 этот момент хуже реализован и пересмотрен в 5.6.

...

Рейтинг:

0 / 0

13.02.2014, 13:46:21

| Ответить | Цитировать | Написать

57 сообщений из 57, показаны все 3 страниц

все

Форумы / MySQL [игнор отключен] [закрыт для гостей] / Partitioning again..

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?all=1&fid=47&tid=1835225]:	0ms
get settings:	7ms
get forum list:	18ms
check forum access:	3ms
check topic access:	3ms
track hit:	50ms
get topic data:	9ms
get forum data:	2ms
get page messages:	80ms
get tp. blocked users:	2ms
others:	215ms

total:	389ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы