성숙한 데이터베이스 스키마 디자인은, 고 가용성 높은 확장 성 등의 특성을 가지고 시작하지 않았다, 그것은 사용자의 양이 증가하고, 인프라가 점차 개선되었다. 주로 문제와 솔루션에 대한이 블로그는 다음의 다섯 단계로 응용 프로그램은 대략 나눈 말을 치워 버리고되지 않는 프런트 엔드가 직면 MySQL의 데이터베이스 개발주기를 최적화하기 :
1, 데이터베이스 테이블 디자인
제품 요구 사항 개발 프로젝트에 따라 프로젝트 승인, 개발 장관, 후, 테이블에 작업 개발 엔지니어는 구조 설계의 일부입니다. 데이터베이스의 경우, 제대로 설계되지 않은 경우, 그것은 직접 액세스 속도와 사용자 경험에 영향을 미칠 것입니다 매우 중요합니다. 등등 느린 쿼리, 적절한 색인이없는 비효율적 인 쿼리, 데이터베이스 차단 (교착 상태)와 같은 많은 요인. 물론, 테스트 엔지니어 팀은 버그를 찾고, 스트레스 테스트를 할 것입니다있다. 팀은 엔지니어를 테스트하지 않은 경우, 대부분의 엔지니어는, 데이터베이스 설계의 초기 개발에 대한 너무 많은 합리적인 생각하지 않지만, 완료 및 배달을 달성하기 위해, 액세스의 일정 금액 후 다른 항목, 숨겨진 문제는 가능한 한 빨리 노출 될 이 일을 수정 갈 그렇게 쉬운 일이 아닙니다.
2, 데이터베이스 배포
충분한 하나의 배포가 약 1500 QPS (초 속도 당 쿼리)에 충족되도록 운영 및 유지 보수 엔지니어, 프로젝트 초기에 많은 트래픽이되지 않습니다했다. 고 가용성 고려하면, MySQL의 마스터 사본 + Keepalived은 핫 백업, 일반적인 클러스터 소프트웨어 Keepalived, 하트 비트를 두 번 클릭에서 만들어 질 수있다.
3, 데이터베이스 성능 최적화
당신이 어떤 최적화없이 경우에 일반 X86 서버에 배포는 MySQL을 이동하면 1500에 대한 도달하면, MySQL은 이론 값 정상은 약 2000 QPS, 최적화, 2500 QPS, 그렇지 않으면 방문에이 제기 될 수 있습니다 처리 할 수 있습니다 동시 연결, 데이터베이스 처리 성능이 느린,하지만 여전히 아주 풍부한 하드웨어 리소스를 할 때, 다음 시간은 소프트웨어 문제를 고려해야합니다. 그렇다면 데이터베이스 성능을 최대화하기 위해 재생 만들려면? 한편 MySQL의 인스턴스가 다른 한편으로는 데이터베이스, 운영 체제 및 데이터베이스가 종종 보수적 기본 구성입니다 최적화하는 것입니다에 놀이, 성능을 극대화 할 수 있도록 단일 서버 실행 복수를 할 수 있습니다, 데이터베이스가 특정 한도를 재생해야합니다, 이러한 구성은 할 수 적절하게 조정 가능한 더 많은 연결을 처리합니다.
별 최적화 세 가지 단계가 있습니다 :
3.1 데이터베이스 구성 최적화
이 개 일반적으로 사용되는 MySQL의 스토리지 엔진이 있습니다, 하나는 트랜잭션, 빠른 읽기 성능 처리, 테이블 수준 잠금을 지원하지 않습니다,의 MyISAM입니다. 또 다른 지원, 이노입니다 트랜잭션 처리 (ACID)는, 성능, 낮은 수준의 잠금을 극대화 재생 많은 양의 데이터를 처리 할 수 있도록 설계되어있다.
테이블 잠금 : 작은 오버 헤드가 큰 그레인 로킹 높은 확률 교착은 또한 비교적 복잡하다.
광고 자물쇠 큰 오버 헤드가 상대적으로 높은 소형, 교착 상태의 발생 확률이 낮은, 동시 잠글.
왜 테이블 및 행 잠금이있다? 주로, 데이터 무결성을 보장하기 위해, 예를 들어, 테이블의 사용자 작업이 다른 사용자는이 테이블을 조작하려는, 그들은 사용자가 다른 테이블 및 행 잠금 장치를 작동 할 수 있습니다, 사용자 작업이 완료 순위 것 잠금이 역할입니다. 그렇지 않으면 여러 사용자가 동시에 테이블을 운영, 데이터가 확실히 충돌 또는 이상이 될 것입니다.
위의 견해에 따르면, 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%
= 128K # 크기, 권장 설정 16M 나 32M 버퍼 읽기 read_buffer_size
query_cache_size를을 = 켜짐 # 쿼리 캐시 기능을 열 수
는 query_cache_limit = 1M 번호를 쿼리 캐시 제한 만 1M 다음 질의 결과 캐시되므로 큰 버퍼 풀 커버에 결과 데이터
query_cache_type을 = 16M 번호는 SELECT 조회 결과를 캐시하는데 사용되는 버퍼 크기, 캐시 풀에서 같은 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 #日志缓冲区大小，由于日志最长每秒钟刷新一次，所以一般不用超过16M3.2 커널 최적화
대부분의 MySQL은 리눅스 시스템에 배포하므로 운영 체제의 일부 매개 변수는 MySQL은, 리눅스 커널의 적절한 최적화의 성능에 영향을 미칠 것입니다.
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队列最大长度，加大队列长度可容纳更多的等待连接프로세스가 초과하는 경우 리눅스 시스템에서, 열린 파일의 수는 그렇게 열린 파일 핸들 제한을 조정하기 위해, "너무 많은 파일 열기"메시지를 메시지가 나타납니다 1024의 기본 값을 처리합니다.
# 바이는 /etc/security/limits.conf #은 다음과 같은 구성을 추가 하는 모든 사용자를 대신하여, 당신은 또한 효과를 적용하려면 시스템을 다시 시작하도록 사용자를 지정할 수 있습니다
소프트 NOFILE의 65535
65535 NOFILE 하드 *
ulimit를 즉시 적용 -SHn 65535 # #
3.3 하드웨어 구성
파일 시스템 성능을 향상, 물리적 메모리를 늘리십시오. 열 데이터를 저장하는 경우, 지연 메커니즘이 동기화되지 파일 시스템을 통해 기록 등 조건 리눅스 커널은 버퍼 영역 (시스템 및 데이터 캐시) 메모리 (예를 들어, 버퍼의 사이즈는 동기화 명령의 일정 비율에 도달하거나, 실행)에 할당되고 디스크에. 즉, 큰 물리적 메모리, 더 큰 버퍼 할당 더 캐시 데이터이다. 물론, 서버 장애는 캐시 된 데이터의 일부를 잃게됩니다.
대신 SAS SSD 하드 드라이브, RAID 레벨이 RAID1 + 0으로 조정, 대한 RAID1과 RAID5는 주로 압력 디스크 I / O 측면 후 데이터베이스에서 읽고 더 나은 성능 (IOPS)를 작성합니다.
4, 데이터베이스 스키마 확장
사업의 성장 볼륨으로, 단일 데이터베이스 서버의 성능은 비즈니스 요구를 충족 기계를 추가하는 것을 고려하고 ~ 클러스터를 할 수 없었다. 주요 아이디어는 디스크 I / O 성능을 깨는, 단일 데이터베이스의 부하를 파괴하는 것입니다, 열 데이터는 디스크 I / O 액세스 빈도를 감소 캐시에 저장됩니다.
4.1 복사 리더 메인로부터 분리
생산 환경 때문에 대부분의 데이터베이스는 읽기 때문에 기본 데이터베이스에서 쓰기 작업을 담당하는 다중 마스터 아키텍처의 배포 및 뜨거운 대기를 두 번 클릭 할, 읽기 동작에 대한 책임 여러 데이터베이스에서로드 밸런싱, 부하 분산이 주류를이 LVS, HAProxy, Nginx에.
어떻게 읽고 분리 쓰기? 대부분의 회사 읽고 분리 효율이 상대적으로 높은 작성하는 코드 수준에 있습니다. 또 다른 방법은 별도의 읽기를 달성하고 에이전트에 의해 작성, 엔터프라이즈 애플리케이션 덜 일반적인 에이전트는 MySQL의 프록시, 아메바가있다. 이 데이터베이스 클러스터 아키텍처에서 높은 동시성 크게 증가 데이터베이스 용량은 단일 성능 병목 현상을 해결하기. 데이터베이스에서 데이터베이스에서 처리 2000 QPS는, 프로세스는 쉽게 5 개 QPS 1w 단위 규모의 데이터베이스를 수 할 수 있습니다.
때로는 때 성능을 쓰기, 쓰기 작업의 많은 수의 애플리케이션하지 최대 하나의 비즈니스 요구하는 것입니다 직면했다. 당신이 이중 마스터 할 경우 다른 사용자가이 데이터베이스 작업을 할 수 있기 때문에, 이러한 응용 프로그램의 결과로, 데이터베이스의 데이터 불일치가 발생합니다 동안 두 개의 데이터베이스 업데이트 데이터베이스 데이터 충돌이나 불일치의 운영 결과. 데이터 무결성을 보장하기 위해 하나의 라이브러리를 사용하여 MySQL의 스토리지 엔진 메커니즘 테이블 및 행 잠금에서, 어떻게 하나 개 이상의 중앙 도서관 안에이 문제를 해결하기 위해? MySQL의-MMM이라는 펄 언어 발달 마스터 - 슬레이브 복제 관리 도구의 집합을 기반으로 (마스터 마스터의 MySQL, MySQL은 마스터 - 마스터 복제 관리자가 managerfor 복제),이 도구의 가장 큰 장점은 동시에 데이터베이스 쓰기 동작을 제공하는 것입니다, 효율적으로 데이터 일관성을 보장합니다.
4.2 캐시를 증가
데이터베이스가 다시 캐시에없는 요청 읽기 데이터의 성능을 향상시키기 위해, 결과를 반환하는 경우 데이터베이스 시스템은 캐시, 열 데이터 캐시 메모리를 증가시킵니다. 로컬 캐시와 캐시 구현 분산 캐시가 있습니다, 로컬 캐시는 로컬 서버 나 파일에 캐시 메모리 데이터입니다. 분산 캐시 데이터, 확장 성, 주류 분산 캐시 시스템 memcached를 안정적 레디 스, 빠른, QPS 8w까지 메모리에 캐시 memcached와 성능 데이터, 대량의 캐시 할 수 있습니다. 당신은 레디 스와 데이터 지속성, memcached를 이상의 성능을 선택합니다.
작업 과정 :
4.3 도서관
이 라이브러리는 같은 블로그 라이브러리와 같은 웹, 게시판 등의 다른 데이터베이스로 절단 다양한 비즈니스 관련 테이블로 구분됩니다. 트래픽이 무거운 경우, 또한 도서관 아키텍처, 더 과도한 압력을 피하기 위해 하나의 라이브러리에서 분할 후 샷을 호출합니다.
표 4.4
일본어 TV 드라마가 삽입의 결과로, 테이블의 데이터 조각의 수백만을 가지고 데이터베이스의 데이터의 양을 증가 및 쿼리 작업이 너무 오래 걸리 어떻게 단일 테이블 압력을 해결하기 위해? 여러 작은 테이블에 테이블을 분할 할 것인지 여부를 고려해야합니다, 스트레스를 줄이고 처리 효율을 향상시킬 수있는 하나의 테이블이이 서브 테이블이라고합니다.
하위 테이블 기술은 당신이 또한 서브 미터, 많은 비교적 간단한을 달성하기 위해 병합 스토리지 엔진을 사용하여, SQL 문에서 프로그램 코드를 수정, 또한 수동으로 다른 테이블을 만들려면 너무 많은 문제입니다. 포인트 테이블되면, 프로그램은 전체 영업 테이블은 테이블은 항상 다른 작은 테이블에 압력에 할당 된 데이터 만 포인트 테이블의 일부 사이의 관계 및 업데이트 데이터 모드, 다른 쿼리를 기반으로 전체 테이블을 저장하지 않습니다 하여 증가 동시성 및 디스크 I / O 성능을 제공합니다.
서브 테이블은 수평 및 수직 분할 분할로 나누어 져 있습니다 :
수직 분할 : 원래 테이블 필드 분할 다중 테이블의 많은 테이블의 폭의 문제를 해결합니다. 또한 별도의 필드에 큰 테이블을 넣을 수 있습니다, 공통 테이블에 필드를 분리 할 수 또는 밀접하게 관련 분야 테이블을 넣어.
분할 레벨 : 복수의 테이블에 나타난 원래 분할 각 테이블 구조는 대형 단일 테이블 데이터의 문제를 해결하기 위해, 동일하다.
4.5 파티션
데이터 구조 (예를 들면, 범위,리스트, 해시 등)에 나타난 필드에 따라 테이블의 복수의 블록들로 분할 한 후에, 이들 블록은 디스크 또는 다른 디스크 파티션 표면 상에있을 수있다 또는 테이블하지만 데이터의 해시에 위치하는 복수의이 방법에서, 다수의 디스크를 동시에함으로써, I / O에 판독 달성 비교적 간단한 쓰기 성능을 향상 디스크, 다른 요청을 처리한다.
참고 : 주로 프로그램 원숭이에 의해 실현 캐시, 서브 라이브러리, 하위 테이블과 파티션을 추가합니다.
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.log5.3 데이터베이스 백업
데이터베이스의 백업은 가장 기본적인 일이지만, 또한 가장 중요한, 그렇지 않으면 결과가 심각하다, 당신은 알고있다! 데이터베이스가 크기 때문에 그러나, G 수백, 백업은 종종 매우 시간이 걸리는, 그래서 데이터베이스에 많은 양의 데이터에 대한 고효율 백업 전략의 관점에서 선택은 일반적으로 증분 백업을 사용하여. 백업 및 복구가 더 이상보다 소요 그래서, 논리적 백업이기 때문에 xtrabackup 등 인기있는 백업 도구 mysqldump는, mysqlhotcopy는, 소규모 데이터베이스에 더 적합 mysqldump에. mysqlhotcopy 및 xtrabackup, 우리는 xtrabackup 사용하는 것이 좋습니다 뜨거운 복사본 서비스의 데이터베이스에 영향을주지 않고, 물리적 백업, 빠른 백업 및 복구 속도, 증분 백업을 지원합니다.
데이터베이스 복구 5.4
때로는 MySQL 서버 테이블에 손상을 줄 수 있습니다 갑작스런 정전, 비정상 종료, 테이블 데이터를 읽을 수 없습니다. 그럼 당신은 MySQL의 수리, myisamchk가와 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에, 비 관계형 데이터베이스, 데이터, 고성능의 대량 해고, 또한 관계형 데이터베이스의 특정 측면의 부족을 보충하기 위해, 대부분의 기업들은 사업의 점진적 일부가 등등하여 MongoDB, HBase를하고 NoSQL에,에 데이터베이스에 저장 될 수 있습니다. 같은 HDFS와 같은 데이터 저장 분산 파일 시스템, GFS는 좋아한다. 데이터는 대규모 컴퓨팅 하둡, 불꽃, 폭풍 등을 이용하여 분석 하였다. 이들은 운영과 첨단 기술의 유지 보수에 관련된, 또한 작은 파트너 함께에 저장의 주요 학습 객체입니다! 블로거가 더 나은 최적화를 가지고있는, 당신과 함께 공유 오신 것을 환영합니다.