не придирчивости ради, а интереса для что плохого в том, что кто-нибудь в этом чате обращается на английском?

То, что есть куча необразованного быдла типа меня, которое не поймёт и которому будет обидно?

А ещё хуже - будут те, кто поймёт не так

теоретически такой барьер можно решить ботом переводчиком ?

Нельзя, боты не могут нормально переводить

Всем привет, Нашел статью, что пагинацию лучше делать с использованием WHERE id > n, и не юзать LIMIT OFFSET. Насколько статья актуальна? И второй вопрос: как запоминать контекст, если с пагинацией через LIMIT/OFFSET все ясно, то тут сходу не могу сообразить. http://use-the-index-luke.com/no-offset

LIMIT OFFSET надежнее. Почему через ID может быть плохо: например ты хранишь ссылки на страницы. В разделе с пагинацией их накопилось 300. Есть в другом разделе 100. Администратор решает переместить из первого раздела страницы во второй. ID остались прежние, а ссылки поменялись.

@heavycharged более чем актуально. А вот второго вопроса я если честно не очень понял.

@viczem актуально только если пагинацию щёлкают в момент переноса

Только один момент. Если ключ составной, а выбирается по части ключа, то ид заменить на следующую по порядку часть, чтобы не было filesort!

@heavycharged более чем актуально. А вот второго вопроса я если честно не очень понял.

ну вот допустим пагинация у нас, пользователь открыл 5 страницу, всего 100 результатов на странице, сортировка по дате создания, тогда ORDER BY created_at LIMIT 100 OFFSET 500 это значит что с 500 по 600 результат, отсортировав по created_at а теперь то же самое, только WHERE id < ? Как нам узнать, что пользователь на 5 странице с сортировкой по дате создания, какой ID нужно передавать в запросе.

получается что нужно запоминать контекст где пользователь находился в последний раз, и передавать его в URL, допустим: /movies?orderBy=date&last_id=1234

Ну так это же не совсем ид)))) Если данные разрознены, то надо либо оставлять оффсет, либо делать другие неприятные вещи. Например, при первом запуске делать агрегацию по ключу (будет быстро) и сохранить позиции between твоих дат.

не понимаю чем этот метод лучше LIMIT OFFSET - быстрее отработает? сомневаюсь в этом

Ну так это же не совсем ид)))) Если данные разрознены, то надо либо оставлять оффсет, либо делать другие неприятные вещи. Например, при первом запуске делать агрегацию по ключу (будет быстро) и сохранить позиции between твоих дат.

че-то не пойму, зачем offset. данные сначала сортируются по created_at, потом по last_seen_id, потом просто limit делаем и все. индекс на created_at висит. вроде в последнем MySQL индексы группируются (не нужно делать составные индексы).

да я тоже не понимаю :) просто искал как делать пагинацию правильно))

и заинтересовал данный вопрос, решил спросить у знающих

"вроде в последнем MySQL индексы группируются" - лучше б они этого не делали...

в табличке максимум 70к записей

думаю сервер не споткнется

тем более индексы есть

да я тоже не понимаю :) просто искал как делать пагинацию правильно))

вот тут с картинками объясняют как правильно: https://www.percona.com/files/presentations/ppc2009/PPC2009_mysql_pagination.pdf

вот тут с картинками объясняют как правильно: https://www.percona.com/files/presentations/ppc2009/PPC2009_mysql_pagination.pdf

спасибо, почитаю.

``Народ можетт кто подсказать, почему автоинкримент глючно работает?

не всегда идет последовательно

что может быть? :(

Транзакции были откачены

Ещё вариант: ON DUPLICATE KEY поднимает автоинкремент.

ON DUPLICATE KEY стоит, точно, не знал, спасибо

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

Yes, if it's local in most cases

Hello guys! I have a need that is to extract the information of which size of each database on my server. I got a query, but it brings me 2 data: information_schema and the table I really want.

SELECT table_schema 'TABLE_NAME', round(sum( data_length + index_length ) / 1024 / 1024) "Size in MB" FROM information_schema.TABLES GROUP BY table_schema like 'TABLE_NAME ;

Is the actual size only the basis that I use or should I consider the sum of both tables listed to know how much hard drive is being consumed?

Thank you!

Is the actual size only the basis that I use or should I consider the sum of both tables listed to know how much hard drive is being consumed?

this is answered in detail here: https://www.percona.com/blog/2016/01/26/finding_mysql_table_size_on_disk/

this is answered in detail here: https://www.percona.com/blog/2016/01/26/finding_mysql_table_size_on_disk/

????

всем привет. на собеседовании задали вопрос, до сих пор не понял, что хотели от меня услышать. "что самое страшное может нам показать план выполнения запроса sql?". может кто-то подсказать? )

Рекурсию ?

В восьмой версии ввели оную?

А так type=all наверное, да filesort)))))

всем привет. на собеседовании задали вопрос, до сих пор не понял, что хотели от меня услышать. "что самое страшное может нам показать план выполнения запроса sql?". может кто-то подсказать? )

независимо от того, какой ответ они ожидали услышать, с этим ответом можно поспорить ?

На самом деле, они просто хотели узнать, чего именно боишься ты))))

На самом деле, они просто хотели узнать, чего именно боишься ты))))

кстати, а ты разобрался с той бедой с ref/index access?

@alexey_kopytov Кроме PREPARE ничего так и не придумал((((

но PREPARE - ещё та дрянь конечно...

а чем PREPARE помогает?

я сначала собираю айдишники груп конкатом. А потом через PREPARE делаю запрос "IN ()"

ух, забористо

Ну, это единственное, что я смог придумать(((

у меня времени было не особо. всё, что я увидел — это то, что в "правильном" тестовом запросе на самом деле используется full index scan (type=index), и вряд ли бы ты заходел увидеть такое в join-е

но в джойне используется ref access, который действительно использовал только первую keypart. а по-другому этот тип и не умеет

тебе на самом деле там нужен type=range. но заставить оптимизатор его использовать на тестовом примере у меня с разбегу не получилось

вот у меня тоже range получился только варианттом с PREPARE.

Пока так сделал на интересующем запросе, будет время - ещё попробую подумать. Но так хотя бы работаетт

range, обе части в "used_key_parts" - всё что доктор прописал

но енкрасиво и лишний запрос

я попробую ещё поиграться. на другом примере range access в джойнах довольно легко было получить, почему здесь он упёрся в ref — пока не понимаю

Я тоже ещё пытаюсь тему изучать. Оптимайзер_свитч весь перещёлкал, запрос как только не перестраивал. Ладно, надеюсь со временем найдётся более красивое решение. А пока - и так сойдёт?

всем привет, а кто нить подскажет тут по настройке mysql ?

или тут только запросы обсуждатся?

не только запросы

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

[mysqld] slow_query_log = 1 slow_query_log_file = /var/log/mariadb/mariadb-slow.log long_query_time = 10 #log-queries-not-using-indexes innodb_log_file_size=12M tmp_table_size=50M max_heap_table_size=50M #query_cache_limit=20M max_connections=100 innodb_buffer_pool_size = 100M connect_timeout=3 join_buffer_size=2M max_allowed_packet=10M table_cache=1000 sort_buffer_size=256K read_buffer_size=128K read_rnd_buffer_size=4M key_buffer=256M #innodb_buffer_pool_size = 3G local-infile=0 performance_schema = ON innodb_log_file_size=12M innodb_buffer_pool_instances=3 #max_connections = 600 max_user_connections=100 key_buffer_size = 512M myisam_sort_buffer_size = 64M #read_buffer_size = 1M table_open_cache = 5000 thread_cache_size = 384 wait_timeout = 5 #connect_timeout = 10 #tmp_table_size = 256M #max_heap_table_size = 128M #max_allowed_packet = 64M net_buffer_length = 16384 max_connect_errors = 10 concurrent_insert = 2 #read_rnd_buffer_size = 786432 bulk_insert_buffer_size = 8M query_cache_limit = 5M query_cache_size = 0 query_cache_type = 0 query_prealloc_size = 262144 query_alloc_block_size = 65535 transaction_alloc_block_size = 8192 transaction_prealloc_size = 4096 max_write_lock_count = 8 slow_query_log log-error external-locking=FALSE open_files_limit=50000

вот такой конфиг - но постоянно падает коннект

Aborted connection 99877 to db: ошибка соедиениеяhost: 'localhost' (Got timeout reading communication packets)

соответсвенно отвалвается nginx с 502 ошибкой

А ты уверен, что дело в сервере, а не в коннекторе или сети?

на одном сервере все

локально

это не показатель))))

А вообще, вотт например у перконы целая статья была, куда копнуть: https://www.percona.com/blog/2016/05/16/mysql-got-an-error-reading-communication-packet-errors/

Понятно, что це не мария, но я не думаю, что будут большие различия в этом плане

I strongly recommend changing the application logic to properly close connections at the end of an operation.

но программерам то не докажешь что нужно так делать

все ж умные нынче

я на самом деле уже много перерыл в интеренете

менял и так и сяк - попробовал тулзу в помощь по оптимизации

та что на гите

поставь евент, который будет делать KILL всех соединений, которые будут висеть в слипе больше определённого промежутка времени, удиви программеров))))

У меня такой есть. Правда, пользую тока в крайннем случае ручным запуском)))) Ибо нефиг!

Variables to adjust: join_buffer_size (> 2.0M, or always use indexes with joins) tmp_table_size (> 50M) max_heap_table_size (> 50M) innodb_buffer_pool_size (>= 484M) if possible. innodb_log_file_size should be (=12M) if possible, so InnoDB total log files size equals to 25% of buffer pool size. wsrep_slave_threads= Nb of Core CPU * 4 gcs.fc_limit= wsrep_slave_threads * 5 gcs.fc_limit= wsrep_slave_threads * 5 gcs.fc_factor=0.8 innodb_flush_log_at_trx_commit = 0 set up parameter wsrep_notify_cmd to be notify set up parameter wsrep_sst_method to xtrabackup based parameter

вот такое выдает тюнер

было бы там соединений за несколько деясяток тыш, а так 20-100

в среднем

Variables to adjust: join_buffer_size (> 2.0M, or always use indexes with joins) tmp_table_size (> 50M) max_heap_table_size (> 50M) innodb_buffer_pool_size (>= 484M) if possible. innodb_log_file_size should be (=12M) if possible, so InnoDB total log files size equals to 25% of buffer pool size. wsrep_slave_threads= Nb of Core CPU * 4 gcs.fc_limit= wsrep_slave_threads * 5 gcs.fc_limit= wsrep_slave_threads * 5 gcs.fc_factor=0.8 innodb_flush_log_at_trx_commit = 0 set up parameter wsrep_notify_cmd to be notify set up parameter wsrep_sst_method to xtrabackup based parameter

ну это ещё на что-то похоже. оригинальные настройки были вообще для как мобильного телефона. buffer pool в 100M, log file на 12M. я уж и забыл, когда последний раз такое видел

Так может там БД на 50 метров и больше и не надо)))))

сказали "для нагруженного сервера". нет, ну разные нагруженные сервера бывают, я не спорю

кстати, вот средняя температура по больнице для постгреса: https://speakerdeck.com/def/blits-doklad-na-pgconf-dot-russia-2018

там даже всё более-менее понятно, но меня особенно впечатлило 240K TPS суммарно на 500 инстансов. это какие-то смех и слёзы

Пол транзакции, ничё так)))))

Я надеюсь, имеются ввиду хотя бы транзакции, включающие в себя запись. Если эта сттатистика включаетт в себя и чисто читаюющие, то жизнь как-то не удалась у них

полтысячи, но это тоже ни о чём. я всегда подозревал, что весь этот наш напудренный хайлоад занимается фигнёй в среднем по больнице. вот это документальное подтверждение

Средняя загрузка диска 50% - это же жесть и не хай-лоад ни разу.