Зрелый дизайн схемы базы данных не начал иметь высокую доступность, масштабируемые и других характеристик, то с увеличением количества пользователей, инфраструктура постепенно улучшается. Этот блог в основном о проблемах и решениях для оптимизации MySQL цикла разработки базы данных, с которой сталкивается передним концом приложение не отложить в стороне, чтобы сказать, грубо разделить на следующие пять этапов:
1, дизайн таблицы базы данных
После утверждения проекта, Министерство развития, в соответствии с проектами развития требований к продукции, инженеров-разработчиков, работающих на столе является частью структурного дизайна. Для базы данных, это очень важно, если должным образом не разработан, он будет непосредственно влиять на скорость доступа и пользовательского опыта. Многие факторы, такие как медленные запросы, неэффективные запросы без надлежащей индексации, закупорка базы данных (тупиковая) и так далее. Конечно, есть инженеры-испытатели команда сделает стресс-тесты, ищет ошибку. Для команды не испытала инженер, большинство инженеров не думать слишком много о начале разработки проекта базы данных является разумным, но для достижения завершения и доставок, а также другие предметы после определенного количества доступа, скрытые проблемы будут выставлены как можно скорее, то это не так легко идти, чтобы изменить вещи.
2, развертывание базы данных
Инженеры по эксплуатации и техническому обслуживанию играли, в начале проекта не будет иметь много трафика, так что один развернуть достаточно для удовлетворения примерно 1500 КПТ (запросов в секунду). Учитывая высокую доступность, может быть сделано из главной копии MySQL + Keepalived дважды щелкните горячее резервное копирование, общее программное обеспечение кластера Keepalived, Heartbeat.
3, производительность базы данных оптимизации
Если переместить MySQL развернут на обычный сервер X86, в том случае, без какой-либо оптимизации MySQL Теоретическое значение нормального может обрабатывать около 2000 КПТ, оптимизирована, может быть увеличена до 2500 КПТ, в противном случае, посещениями при достижении около 1500 при одновременных соединений, производительность обработки баз данных будет медленнее, но все еще очень богатые аппаратные ресурсы, то время, чтобы рассмотреть проблему программного обеспечения. Так как сделать базу данных, чтобы играть, чтобы максимально увеличить производительность? С одной стороны, может быть один сервером запустить несколько экземпляры MySQL позволяют играть, чтобы максимально увеличить производительность, с другой стороны, является оптимизация базы данных, операционные системы и базы данных часто являются более консервативной конфигурацией по умолчанию, базы данных будут играть определенный предел, эти конфигурации могут надлежащим образом регулировать, обрабатывать большее количество соединений, как это возможно.
Специфическая оптимизация Есть три уровня:
Оптимизация конфигурации базы данных 3.1
Есть два обычно используются для хранения MySQL двигателя, один MyISAM, он не поддерживает транзакцию, быстро прочитать производительность обработки, таблица уровня блокировки. Другой ЬшоВВ, поддерживает обработку транзакций (КИСЛОТА), предназначена для обработки больших объемов данных, чтобы играть максимальную производительность, блокировки на уровень строк.
Таблица блокировка: небольшие накладные расходы, крупнозернистый замок, тупиковая высокая вероятность, осложняются также относительно низкого.
Line Lock: большие накладные расходы, блокировка небольшого размера, низкая вероятность возникновения тупиковой ситуации, одновременно также относительно высок.
Почему таблица и блокировки строк это? В основном для обеспечения целостности данных, например, операция пользователя в таблице, другие пользователи также хотят работать в этой таблице, то они бы ранжировании операция пользователя завершена, пользователи могут работать другие таблицы и строки блокировки блокировка эта роль. В противном случае несколько пользователей могут одновременно работать таблицу, данные, безусловно, будет конфликт или ненормальным.
Согласно приведенному выше мнению, использовать механизм хранения InnoDB является лучшим выбором, но и MySQL5.5 позже в двигателе хранения по умолчанию. Каждый двигатель, связанные параметры хранения больше параметров производительности базы данных главного удара перечислены ниже.
公共参数默认值：
max_connections = 151 #同时处理最大连接数，推荐设置最大连接数是上限连接数的80%左右
sort_buffer_size = 2M #查询排序时缓冲区大小，只对order by和group by起作用，可增大此值为16M
open_files_limit = 1024 #打开文件数限制，如果show global status like 'open_files'查看的值等于或者大于open_files_limit值时，程序会无法连接数据库或卡死 Параметры MyISAM по умолчанию:
key_buffer_size = # 16M размер индекса буфер, как правило , 30-40% физической памяти при условии
read_buffer_size = 128K # считывает размер буфера, рекомендуемые параметры 16M или 32M
query_cache_type = открыть ON # запроса функции кэша
query_cache_limit = 1M # запроса лимит кэша, только 1M результаты следующего запроса кэшируются, поэтому полученные данные в буфер большего размера крышки бассейн
query_cache_size = 16M # посмотреть размер буфера , используемого для кэширования SELECT , результаты запроса, в следующий раз тот же запрос на выборку непосредственно из пула кэша возвращать результаты, это значение может быть соответствующим образом умножается
InnoDB参数默认值：
innodb_buffer_pool_size = 128M #索引和数据缓冲区大小，一般设置物理内存的60%-70%
innodb_buffer_pool_instances = 1 #缓冲池实例个数，推荐设置4个或8个
innodb_flush_log_at_trx_commit = 1 #关键参数，0代表大约每秒写入到日志并同步到磁盘，数据库故障会丢失1秒左右事务数据。1为每执行一条SQL后写入到日志并同步到磁盘，I/O开销大，执行完SQL要等待日志读写，效率低。2代表只把日志写入到系统缓存区，再每秒同步到磁盘，效率很高，如果服务器故障，才会丢失事务数据。对数据安全性要求不是很高的推荐设置2，性能高，修改后效果明显。
innodb_file_per_table = OFF #默认是共享表空间，共享表空间idbdata文件不断增大，影响一定的I/O性能。推荐开启独立表空间模式，每个表的索引和数据都存在自己独立的表空间中，可以实现单表在不同数据库中移动。
innodb_log_buffer_size = 8M #日志缓冲区大小，由于日志最长每秒钟刷新一次，所以一般不用超过16MОптимизация ядра 3.2
Большинство MySQL развернуты на системе Linux, поэтому некоторые параметры операционной системы также влияет на производительность MySQL, правильной оптимизации ядра Linux.
net.ipv4.tcp_fin_timeout = 30 #TIME_WAIT超时时间，默认是60s
net.ipv4.tcp_tw_reuse = 1 #1表示开启复用，允许TIME_WAIT socket重新用于新的TCP连接，0表示关闭
net.ipv4.tcp_tw_recycle = 1 #1表示开启TIME_WAIT socket快速回收，0表示关闭
net.ipv4.tcp_max_tw_buckets = 4096 #系统保持TIME_WAIT socket最大数量，如果超出这个数，系统将随机清除一些TIME_WAIT并打印警告信息
net.ipv4.tcp_max_syn_backlog = 4096 #进入SYN队列最大长度，加大队列长度可容纳更多的等待连接В системе Linux, если процесс превышает количество открытых файлов значение 1024 по умолчанию, он предложит «слишком много открытых файлов» сообщение, поэтому для настройки открытого лимита открытых файлов.
# Vi /etc/security/limits.conf # добавьте следующую конфигурацию, от имени всех пользователей, вы можете также указать пользователя , чтобы перезагрузить систему , чтобы принять эффект
Soft nofile 65535
* Жесткий nofile 65535
# 65535 # ULIMIT -SHn немедленно вступили в силу
Конфигурация 3.3 Оборудование
Увеличение физической памяти, повысить производительность файловой системы. Когда тепло для хранения данных, механизм задержки записываются через файловую систему, и поэтому ядро условия Linux выделяет область буфера (системная и кэшируют данные) из памяти (например, размер буфера достигает определенный процент от команды синхронизации или выполнения) не будет синхронизирован на диск. То есть чем больше физической памяти, тем больше выделение буфера, тем больше данных кэша. Конечно, отказ сервера потеряет часть кэшированных данных.
Вместо жестких дисков SAS SSD, RAID-уровень настраивается на RAID1 + 0, RAID1 и RAID5 относительно чтения и записи более высокой производительности (IOPS), в основном, из базы данных после диска давления аспектов ввода / вывода.
4, расширение схемы базы данных
С ростом объема бизнеса, один производительность сервера базы данных не в состоянии удовлетворить потребности бизнеса, рассмотреть вопрос о включении аппарата, а также сделать ~ кластер. Основная идея заключается в том, чтобы сломать единую нагрузку на базу данных, разбивая производительность дисковых операций ввода / вывода, термический данные хранятся в кэше, уменьшая объем дискового ввода / вывода частоты доступа.
4.1 Копирование читатель отделен от основной
Поскольку в производственной среде, большинство баз данных считываются, поэтому развертывание мульти-мастер архитектуры ответственной за операции записи из основной базы данных, и сделать двойной щелчок на горячее резервирование, балансировка нагрузка из нескольких баз данных, ответственных за операции чтения, балансировки нагрузки имеет мейнстрят LVS, HAProxy, Nginx.
Как читать и писать отдельные его? Большинство компаний на уровне коды для чтения и записи эффективность разделения является относительно высокой. Еще способы достижения отдельного чтения и записи с помощью агента, корпоративных приложений, менее распространенные агенты имеют MySQL Proxy, амебы. В этом кластере архитектуры базы данных, высокий параллелизм значительно увеличена емкость базы данных для решения одиночные узких мест. Если обработка 2000 КООТ из базы данных из базы данных, то этот процесс может быть 5 единиц 1w КООПТ, масштаб базы данных легко.
Иногда, столкнувшись с применением большого количества операций записи, производительность записи не до одного бизнеса. Если вы делаете двойной мастер, столкнется противоречивость данных базы данных, в результате применения этого, потому что разные пользователи могут иметь две операции базы данных, в то время как операционный результат в две базы данных обновления базы данных конфликтов или противоречий. В одной библиотеке использование MySQL механизмы хранения двигателя таблицы и блокировок строк для обеспечения целостности данных, как решить эту проблему в более чем одной главной библиотеки это? На основе набора PERL инструмента управления подчиненной репликации развития языка под названием MySQL-MMM (Master-Master репликации managerfor Mysql, Mysql мастер-мастер менеджер репликации), самым большим преимуществом этого инструмента является обеспечение операции записи базы данных только в то же время, эффективно обеспечивать согласованность данных.
4,2 увеличить кэш
База данных системы, чтобы увеличить кэш, кэш-память для тепловых данных, если база данных возвращает результаты, чтобы улучшить производительность запрашиваемых данных для чтения не в кэше снова. Есть локальный кэш и реализация распределенного кэша кэш, локальный кэш данных кэш-памяти на локальный сервер или файл. Распределенный кэш может кэшировать большие объемы данных, масштабируемость, основной распределенной системы кэширования Memcached, Redis стабильных, Memcached данных производительности кэшируются в памяти, быстро, КПТ до 8Вт. Если вы хотите выбрать сохранение данных с Redis, производительность не менее Memcached.
Процесс работы:
4.3 Библиотека
Библиотека разделена на различные связанные с бизнес-таблиц, вырезанных в различных базах данных, таких как веб-сайтов, ББС, библиотеки блог как. Если трафик является тяжелым, также будет вызывать выстрелы после разделения от архитектуры библиотеки, одной библиотеки для дальнейших избежать чрезмерного давления.
Таблица 4.4
Японские телевизионные драмы увеличить объем данных в базе данных таблицы имеет миллионы кусочков данных, в результате вставки и запрос занимает слишком много времени, как решить давление однотабличного? Вы должны рассмотреть вопрос о том, чтобы разбить таблицу на несколько небольших столиков, один стол, чтобы уменьшить стресс, повысить эффективность обработки, это называется суб-таблицы.
техника Sub-таблица слишком много хлопот, чтобы изменить код программы в SQL отчетности, но и для создания других таблиц вручную, вы можете также использовать механизм хранения данных слияния для достижения субметровых, многие относительно просто. После таблицы точек, программа представляет собой общий операционный стол, стол не всегда хранить данные, только отношения между некоторыми из таблицы точек и режим данных обновлений, общее таблицу на основе различных запросов, назначенные к давлению на другой маленьком столике , тем самым увеличивая параллелизмом и дискового ввода / вывода производительность.
Суб-таблица делится на горизонтальную и вертикальную Сплит:
Вертикальная Сплит: много из нескольких таблиц исходной таблицы поля расщепления, чтобы решить проблему ширины таблицы. Вы не можете отделить поле в общую таблицу, можно также поставить большой стол в отдельном поле или тесно связанные поля поместить таблицу.
Двухуровневые: исходная таблица разделяется на множество таблиц, каждая таблица структуры являются такими же, чтобы решить проблему больших объемов данных из одной таблицы.
4.5 раздела
После того, как данные разделены на множество блоков таблицы в соответствии с полями таблицы в структуре (например, диапазон, список, хэш, и т.д.), эти блоки могут быть на диске или на другой раздел диска, поверхность или на столе, но множество позиций в хэш-данных, таким образом, несколько дисков одновременно обрабатывать различные запросы, тем самым улучшая диск ввода / вывода чтения и записи, относительно просто достичь.
Примечание: Добавьте кэш, суб-библиотеки, вложенные таблицы и разделы в основном реализуемые программы обезьяны.
5, ведение базы данных
Ведение базы данных является одной из основной эксплуатации и технические обслуживание инженер или DBA работы, включая контроль, анализ производительности, такие как настройка производительности, резервное копирование базы данных и восстановление.
5.1 Основные показатели состояния
QPS，Queries Per Second：每秒查询数，一台数据库每秒能够处理的查询次数
TPS，Transactions Per Second：每秒处理事务数
通过show status查看运行状态，会有300多条状态信息记录，其中有几个值帮可以我们计算出QPS和TPS，如下：
Uptime：服务器已经运行的实际，单位秒
Questions：已经发送给数据库查询数
Com_select：查询次数，实际操作数据库的
Com_insert：插入次数
Com_delete：删除次数
Com_update：更新次数
Com_commit：事务次数
Com_rollback：回滚次数
那么，计算方法来了，基于Questions计算出QPS：
mysql> show global status like 'Questions';
mysql> show global status like 'Uptime';
QPS = Questions / Uptime
基于Com_commit和Com_rollback计算出TPS：
mysql> show global status like 'Com_commit';
mysql> show global status like 'Com_rollback';
mysql> show global status like 'Uptime';
TPS = (Com_commit + Com_rollback) / Uptime
另一计算方式：基于Com_select、Com_insert、Com_delete、Com_update计算出QPS
mysql> show global status where Variable_name in('com_select','com_insert','com_delete','com_update');
等待1秒再执行，获取间隔差值，第二次每个变量值减去第一次对应的变量值，就是QPS
TPS计算方法： mysql> show global status where Variable_name in('com_insert','com_delete','com_update');
计算TPS，就不算查询操作了，计算出插入、删除、更新四个值即可。
经网友对这两个计算方式的测试得出，当数据库中myisam表比较多时，使用Questions计算比较准确。当数据库中innodb表比较多时，则以Com_*计算比较准确。5,2 оборота на журнал медленных запросов
MySQL开启慢查询日志，分析出哪条SQL语句比较慢，使用set设置变量，重启服务失效，可以在my.cnf添加参数永久生效。
mysql> set global slow-query-log=on #开启慢查询功能
mysql> set global slow_query_log_file='/var/log/mysql/mysql-slow.log'; #指定慢查询日志文件位置
mysql> set global log_queries_not_using_indexes=on; #记录没有使用索引的查询
mysql> set global long_query_time=1; #只记录处理时间1s以上的慢查询
分析慢查询日志，可以使用MySQL自带的mysqldumpslow工具，分析的日志较为简单。
#mysqldumpslow -t 3 /var/log/mysql/mysql-slow.log #查看最慢的前三个查询
也可以使用percona公司的pt-query-digest工具，日志分析功能全面，可分析slow log、binlog、general log。
分析慢查询日志：pt-query-digest /var/log/mysql/mysql-slow.log
分析binlog日志：mysqlbinlog mysql-bin.000001 >mysql-bin.000001.sql
pt-query-digest --type=binlog mysql-bin.000001.sql
分析普通日志：pt-query-digest --type=genlog localhost.logрезервное копирование базы данных 5.3
Резервное копирование базы данных является самой основной работы, но и самое главное, в противном случае последствия могут быть серьезными, вы знаете! Но так как база данных велика, сотни G, резервное копирование часто отнимает очень много времени, поэтому выбор в отношении стратегии резервного копирования высокой эффективности для большого количества данных в базе данных, как правило, с использованием дополнительных резервных копий. Популярные средства резервного копирования туздЫшпр, Mysqlhotcopy, XtraBackup и т.д., туздЫшпр больше подходит для небольших баз данных, потому что это логично резервное копирование, поэтому резервное копирование и восстановление занимает больше времени, чем это. Mysqlhotcopy и XtraBackup является физическое резервное копирование, быстрое резервное копирование и восстановление скорости, не затрагивая базу данных службы в горячей копии, мы рекомендуем использовать XtraBackup, поддерживает дополнительные резервные копии.
Ремонт базы данных 5.4
Иногда MySQL сервер внезапного сбоя питания, аварийное выключение, может привести к повреждению таблицы, данные таблицы не может быть прочитан. Затем вы можете использовать два инструмента, который идет с MySQL ремонт, затсЫс и mysqlcheck.
myisamchk：只能修复myisam表，需要停止数据库
常用参数：
-f --force 强制修复，覆盖老的临时文件，一般不使用
-r --recover 恢复模式
-q --quik 快速恢复
-a --analyze 分析表
-o --safe-recover 老的恢复模式，如果-r无法修复，可以使用此参数试试
-F --fast 只检查没有正常关闭的表
快速修复weibo数据库:
#cd /var/lib/mysql/weibo
#myisamchk -r -q *.MYI
mysqlcheck：myisam和innodb表都可以用，不需要停止数据库，如修复单个表，可在数据库后面添加表名，以空格分割
常用参数：
-a --all-databases 检查所有的库
-r --repair 修复表
-c --check 检查表，默认选项
-a --analyze 分析表
-o --optimize 优化表
-q --quik 最快检查或修复表
-F --fast 只检查没有正常关闭的表
快速修复weibo数据库:
mysqlcheck -r -q -uroot -p123 weibo
Вот некоторые из основной программы оптимизации я использую MySQL, чтобы подвести итоги за последние несколько лет, ограниченные возможности, некоторые менее всеобъемлющие, но они могут в основном удовлетворять потребности малых и средних баз данных бизнеса.
Поскольку первоначальных намерения реляционных ограничений проектирования баз данных, некоторый BAT компания огромных объемов данных в реляционную базу данных, массовый запрос и анализ данных уже достигают более высокую производительность. Так запустят NoSQL, не-реляционную базу данных, большие объемы данных, высокой производительности, но и компенсировать отсутствие некоторых аспектов реляционных баз данных, большинство компаний постепенно часть бизнеса будет храниться в базе данных в NoSQL, такие как MongoDB, HBase и так далее. хранения данных, распределенные файловые системы, такие как HDFS, GFS нравится. Данные были проанализированы с использованием массивных вычислений Hadoop, Спарк, Storm и тому подобное. Они связаны с эксплуатацией и техническим обслуживанием передовых технологий, является также одним из основных объектов обучения в хранилище, мелкие партнеры вместе на этом! Какие блоггеры имеют лучшую оптимизацию, приветствовать, чтобы поделиться с вами.