MySQL5.7参数优化

innodb_buffer_pool_size 约物理内存的50%-70%

innodb_data_file_path 初始化大小至1G

innodb_log_file_size 1G以上

innodb_flush_log_at_trx_commit 0:最快数据最不完全 1:最慢最安全 2:折中

innodb_max_dirty_pages_pct 25%-50%为宜

innodb_io_capacity 普通机械键盘:1000左右 SSD:10000左右 PCIE-SSD:20000以上

key_buffer_size 32M以下

sync_binlog 0:最快数据最不完全,系统自己决定刷新binlog的频率 1:最慢最安全,每个event刷新一次 N:每N个事务刷新一次

long_query_time 建议设置小于0.5秒

open_files_limit & innodb_open_files 建议65535

max_connections 突发最大连接数的80%为宜,过大容易导致全部卡死

thread_handling = “pool-of-thread” 启动线程池

query_cache_size & query_cache_type 绝大多数情况下是鸡肋,最好关闭 QC锁是全局锁,每次更新QC的内存块锁代价高,很容易出现 waiting for query cache lock状态

ibdata1文件都存储了些什么内容
Data dictionary
Double write buffer
Insert buffer
Rollback segments
UNDO space
Foreign key constraint system tables

ibdata1文件暴增的原因
大量事务,产生大量的undo log
有旧事务长时间未提交,产生大量旧undo log
file i/o性能差,purge进度慢
32bit系统下有bug

ibdata1文件暴增解决
设置独立undo表空间
增加purge线程数,innodb_purge_threads
提高file i/o能力
事务及时提交,不要积压
默认打开autocommit = 1
检查开发框架,确认autocommit=0的地方,事务结束后都有提交和回滚

连接数过高 too many connections
常规的做法:想办法杀掉多余的连接,加大连接数
其实应该是这样:限制连接数,设定max_user_connections 设定额外端口extra-port(便于DBA在数据库最大连接数占满后仍然能连接数据库进行操作)
建议:定时检查,干掉慢查询,避免阻塞,自我保护

MySQL5.7 sys系统数据库

查看是否安装 (5.7+默认安装)
select * from sys.version;

便于人类阅读 结果集类似:background | 2143 | 266.48 ms
select * from host_summary_by_file_io;

便于工具处理 加上”x$” 结果集类似:background | 2148 | 266558291670
如果需要使用”order by”之类的操作的话不能显示 如:266.48 ms
select * from x$host_summary_by_file_io;

谁使用了最多的资源
select * from user_summary;

大部分连接来自哪里
select * from host_summary;

在哪个文件产生了最多的IO
select * from io_global_by_file_by_bytes

哪张表被访问的最多
select * from sys.schema_table_statistics;

哪些语句延迟较大,这些延迟较大的语句有哪些特征
select * from statement_analysis

哪些SQL语句使用了磁盘临时表
select * from statements_with_temp_tables

哪张表占用了最多的buffer pool空间
select * from innodb_buffer_stats_by_table

索引的好处
通过索引过滤,减少需要扫􏰁的记录数量
索引可以帮助服务器避免排序和临时表
索引可以将随机IO变为顺序IO
通过索引覆盖,加快查询

索引的坏处
占用磁盘空间
增加了记录的修改(插入、删除、修改)代价

快速查看每张表的索引情况
select * from schema_index_statistics;

索引的使用需要恰到好处,充分利用索引的优势,避免无用索引、冗余索引等

查看重复索引
select * from schema_redundant_indexes;

查看无用索引
SELECT * FROM schema_unused_indexes;

案例
a字段无索引 全表扫描
select a from t1 where a = 1;

给a字段添加索引
alter table t1 add index idx_a(a);

存在综合排序 不能命中索引
SELECT a,b FROM t1 WHERE a > 666 ORDER BY a, b;

添加组合索引
alter table t1 add index idx_a_b(a, b);

a索引重复 删除a索引
ALTER TABLE t1 DROP INDEX idx_a;

mysql简单整理

 

mysql分区技术(二)

例1.假设你创建了一张表,该表保存20家音像店的职员记录,这20家音像店的编号从1到20。根据store_id将其分成4个分区,可使用range分区。如下图:

1

 

例2.根据离职日期分区,同样使用range分区,如下图:

2

 

例3.list分区与range分区有类似的地方(list好比php中的switch、range好比php中的if…else),假设20家音像店分别在4个区,每个区分别包含如下store_id的音像店。东区:1,2,10,11,19,20 南区:7,8,15,16 西区:4,12,13,14,18 北区:3,5,6,9,17 此时,可使用list分区,如下图:

3

 

例4.基于入职日期hired,按年份平均分布成4个分区,则可使用hash分区,如下图:

4

 

key分区,由于性能较低,一般不推荐使用,具体4个分区的对比,如下图:

5

 

mysql分区技术(一)

类似水平分表,但是它是mysql在物理层进行水平分表,与对应的应用程序来说,它还是一张表
mysql5.1开始以插件的形式支持分区
mysql常用分区类型有 RANGE LIST HASH KEY
show plugins; //通过show plugins命令,如果显示partition active 表示分区插件已启动
innodb引擎的表有两种表空间:共享表空间、独占表空间
如果innodb的表要做分区,必须是独占表空间,而且个人也比较建议使用独占表空间(性能更高、灵活性更高),唯一的缺点就是占用硬盘容量更大

 

从测试可看出,如果表的数据量不是很大的情况下,建立索引可以起到同样的优化效果,只有表数据量较大(估计2000万条以上吧- -)或者一些不方便建立索引的表上,选择分区技术也是不错的方案。

事务简介

事务的ACID原则:

原子性(Atomicity):一个事务要么全部执行,要么不执行。也就是说一个事务不可能只执行了一半就停止了。比如你从取款机取钱,这个事务可以分成两个步骤:1划卡、2出钱。不可能划了卡,而钱却没出来。这两步必须同时完成。要么就不完成。

一致性(Consistency):事务的运行并不改变数据库中数据的一致性。例如,完整性约束了a+b=10,一个事务改变了a,那么b也应该随之改变。

隔离性(Isolation):两个以上的事务不会出现交错执行的状态。因为这样可能会导致数据不一致。

持久性(Durability):事务运行成功以后,就系统的更新是永久的。不会无缘无故的回滚。

事务隔离级别设置:

 

隔离级别对应的脏读、不可重复读、幻读情况如下图:

1

脏读、不可重复读、幻读的解释:

脏读 :脏读就是指当一个事务正在访问数据,并且对数据进行了修改,而这种修改还没有提交到数据库中,这时,另外一个事务也访问这个数据,然后使用了这个数据。

不可重复读 :是指在一个事务内,多次读同一数据。在这个事务还没有结束时,另外一个事务也访问该同一数据。那么,在第一个事务中的两次读数据之间,由于第二个事务的修改,那么第一个事务两次读到的的数据可能是不一样的。这样就发生了在一个事务内两次读到的数据是不一样的,因此称为是不可重复读。例如,一个编辑人员两次读取同一文档,但在两次读取之间,作者重写了该文档。当编辑人员第二次读取文档时,文档已更改。原始读取不可重复。如果只有在作者全部完成编写后编辑人员才可以读取文档,则可以避免该问题。

幻读 : 是指当事务不是独立执行时发生的一种现象,例如第一个事务对一个表中的数据进行了修改,这种修改涉及到表中的全部数据行。同时,第二个事务也修改这个表中的数据,这种修改是向表中插入一行新数据。那么,以后就会发生操作第一个事务的用户发现表中还有没有修改的数据行,就好象发生了幻觉一样。例如,一个编辑人员更改作者提交的文档,但当生产部门将其更改内容合并到该文档的主复本时,发现作者已将未编辑的新材料添加到该文档中。如果在编辑人员和生产部门完成对原始文档的处理之前,任何人都不能将新材料添加到文档中,则可以避免该问题。

通常在实际业务中,我一般使用默认隔离级别,但是可以通过for update对重要业务加锁

 

推荐地址:http://www.cnblogs.com/zemliu/archive/2012/06/17/2552301.html