mysql 优化(3)

using filesort 不能利用索引来进行分组或排序,利用filesort算法在内存或者磁盘进行排序
using temporary 先在内存中进行分组,归并等操作,不够利用磁盘

SELECT id FROM table ORDER BY RAND() LIMIT n;
优化成=&get;
SELECT id FROM table t1 JOIN (SELECT RAND() * (SELECT MAX(id) FROM table) AS nid) t2 ON t1.id &get; t2.nid LIMIT n;

两个表left join,一般不会被改写顺序,
而三个以上的left join他们之间也会自动选择顺序了
SQL优化要点
1、 消除type = ALL
2、 消除 using filesort
3、 消除 using temporary
4、 多表连接时,注意连接顺序是否我们提交的顺序,是否被改写了(有时候,被改写了反而更好,不一而论)
5、 注意 key_len 是否达到了预期,整个联合索引尽可能都被利用
其他优化建议
• 使用长连接避免连接开销。或者加大thread_cache_size,或者使用thread pool;
• 重要业务上线前,关键SQL必须逐个EXPLAIN分析,确保都有适当的索引;
• 请求频率很高的表上禁止运行长读写事务,避免发生严重锁等待等性能问题;
• 类似长URL(低于255长度)列检索,建议先进行HASH后创建索引,其检索效率会高很多倍;
• 区分冷热表,让热数据尽可能放在buffer中,提高读写效率;
• 如果需要经常统计结果,建议新增计数器,或者使用redis、mc来代替MySQL;
• 非精确性统计表总记录数时,可以执行SHOW TABLE STATUS查看估算结果;
• 所有列类型都设置默认值,严禁允许默认为NULL值的;
• 如果不能把多个大字段(长VARCHAR、TEXT、BLOB类型)分离到子表的话,就想办法合并成一个大字段,避免频繁的off-page;
• 个别时候可能需要采用冗余字段来存储,比如部分长度(尤其是取最右边的长度),或者反向存储,方便特殊的检索需求;
• 频繁读取的热数据,尽可能缓存在redis、mc中,哪怕只缓存10秒,如果每秒请求1000次的话,也可以减少1万次请求;
• 可以的话,采用多行记录同时INSERT,或者LOAD方式批量写入,提高写入效率,但也要避免锁时间太久的问题;

Index Condition Pushdown(ICP)
• 5.6以上,优化索引查询效率
• 以前:先检索全部记录,而后进行一次过滤
• 现在:边检索记录,边进行过滤
• 好处:降低SQL层得到的结果集,提高处理效率
• 优化支持range、ref、eq_ref、eq_or_null类型查询
• 查询优化器提示:Using index condition

• 在不支持ICP之前,MySQL进行索引查询时,会先根据索引查询记录,再根据WHERE条件来进行过滤。
• 在支持ICP后,MySQL在根据索引查找的同时,会根据WHERE条件对结果进行过滤,将WHERE条件的过滤操作放在存储引擎层,这样一来,
在一些查询中,ICP会大大提高上层SQL层(SERVER层)读取记录(fetch)效率,从而提高整体tps。

show global variables like 'optimizer_switch';
启用ICP:
set global optimizer_switch = "index_condition_pushdown=on";
关闭ICP:
set global optimizer_switch = "index_condition_pushdown=off";

新特性:MRR & BKA
MRR(Multi-Range Read)
• 5.6以上,减少磁盘随机访问,将随机访问转变成顺序访问,提高IO性能
• 适用于range、ref、eq_ref类型查询
• 数据访问较为顺序,查询辅助索引时,对查询结果先按照主键(ROWID)进行排序,并按照主键排序后的顺序,进行顺序查找
• 减少buffer pool中的页面被替换次数
• 批量处理对索引的查询操作
MRR工作方式:
• 将查询到的辅助索引键值放在一个缓冲中,这时缓冲中的数据是根据辅助所以进行排序的
• 将缓冲中的键值根据 ROWID进行排序
• 根据ROWID的排序顺序来访问实际的数据文件

新特性 BKA(Batched Key Access)
在MySQL 5.6中,BKA(Batched Key Access)联接算法可同时用于表连接以及join buffer时的索引访问。
BKA算法支持inner join、outer jon、semi-join,以及nested-outer join。BKA算法使得表扫描效率更高,以此实现JOIN优化。
此前BNL(Block Nested-Loop)联接算法只能用于inner join优化,现在也支持outer join、semi join、以及nested outer join等。

InnoDB引擎优化 - innodb buffer pool转储、预热
转储文件名为ib_buffer_pool, 转储的文件中只记录了space id和page no,所以非常小
InnoDB引擎优化 - read only transaction,只读事务
默认开启事务是READ WRITE,可以在开启事务时指定: START TRANSACTION READ ONLY;
如果以autocommit运行select,则视其为READ ONLY
只读事务不会为其创建事务,提高只读效率,只读事务减少了创建read view的开销,因为这是个全局锁竞争的热点。
InnoDB引擎优化 - 物化Innodb表的统计信息
控制选项:innodb_stats_persistent
当开启该选项后,就会将表的统计信息记录到ibdata中,只有手动执行ANALYZE TABLE才会对其进行更新。
在5.6中,引入的一个新参数innodb_stats_auto_recalc用于控制是否进行自动统计信息计算。当表上的记录修改超过1/16比例,或者总共超过20亿行时,
或者访问information_schema下的一些特定表,就会对统计信息重新计算;这只对在建表时打开了innodb_stats_persistent或者指定了建表选项STATS_PERSISTEND=1生效,
采样page的个数通过参数innodb_stats_persistent_sample_pages来控制(实际读取的page数会大于该值)。

information_schema.TABLES
information_schema.STATISTICS
information_schema.PARTITIONS
information_schema.KEY_COLUMN_USAGE
information_schema.TABLE_CONSTRAINTS
information_schema.REFERENTIAL_CONSTRAINTS

InnoDB引擎优化 - 引入独立page cleaner thread和purge thrad
启用独立的page cleaner线程和 purge thread,通过选项 innodb_puge_threads 来控制。在5.6版本下,还只能设置为1,从5.7开始,就可以设置成更大值
InnoDB引擎优化 - 死锁检测增强
启用 innodb_print_all_deadlocks 选项,即可将全部死锁信息打印输出到日志文件中,在以前,只能在show engine innnodb status中打印最后一次死锁信息
InnoDB引擎优化 - 独立undo表空间
innodb_undo_tablespaces #undo 表空间的个数,将所有的回滚段平分到这么多个ibd表空间文件中,这个值一旦设置,则不可更改。
配置这个及下面的选项,是为&get;了将undolog从Ibdata中独立出来,并且由于undo log是随机写,可以放到SSD盘上来提高性能
innodb_undo_directory #表示undo log表空间文件的路径,启动前设置
innodb_undo_logs #等同于老版本的innodb_rollback_segments,一个事务中最多可以多少个回滚段。
InnoDB引擎优化 - InnoDB page size增强
支持4K、8K格式,适用于绝大多数行平均大小较低值的场景。
从5.7开始,则新增支持32K、64K格式,以适应数据仓库中长日志格式场景。

InnoDB引擎优化 - page checksum增强
innodb_checksum = 0|1,是否校验innodb磁盘文件
innodb_checksum_algorithm #更快的checksum算法(crc32), innodb|crc32|none|strict_innodb|strict_crc32|strict_none
binlog_checksum = CRC32 | NONE,校验算法
master_verify_checksum = 0|1,读取binlog时,是否校验
slave_sql_verify_checksum = 0|1,在slave上读取relay log时,是否校验relay log

5.6新特性:EXPLAIN增强
支持DML的EXPLAIN,但是需要注意可能有不准确的情况。
EXPLAIN结果中,type列有时候会变成range,但实际上是use index的,和改成SELECT后的执行计划不一致。
而如果是多表的DML执行计划解析,则没有问题。

5.6新特性:查询优化器跟踪
启用了optimizer_trace功能,和oracle的执行计划类似,可以输出json格式结果,并且开始往CBO方向靠。
http://imysql.com/2014/08/05/a-fake-bug-with-eq-range-index-dive-limit.shtml
http://blog.163.com/li_hx/blog/static/18399141320147521735442/

show tables like ‘INNODB_SYS_%';

5.6新特性:复制增强
1、 开始支持GTID,极大方便了复制的便利性以及可靠性;
2、 支持多线程并发复制,不过只能是基于database级别的,意义不大,可以用percona或者mariadb分支特性;
3、 slave库延迟更新,防止误操作;
4、 binlog_row_image = full|minimal|noblob,减少binlog大小;同时binlog和relay log也支持crash safe了,上面checksum已介绍过;
5、 支持将master、slave、relay log info等信息记录在innodb表中,取代原先的写文件做法,提高可靠性;
6、 可以利用mysqlbinlog构建一个binlog server:--read-from-remote-server --raw
7、 binlog group commit
Tips:当引入binlog group commit后,sync_binlog的含义就变了,假定设为1000,表示的不是1000个事务后做一次fsync,而是1000个事务组。

5.7新特性:其他
innodb_purge_threads 可以设置大于1,有效的进行purge
InnoDB REDO log size up to 512 Gbyte (日志大小达到了512G,有效的提高了检查点的写入)

mysql选择,percona,mariadb
Percona分支特有选项/参数
enforce_storage_engine
expand_fast_index_creation
² 扩展快速创建索引特性,尽可能避免在一些场景下执行唯一约束、外键约束检查,提高性能
² mysqldump中新增选项 --innodb-optimize-keys,在备份文件最莫问再加上enable keys,以及唯一约束、外键约束检查等
extra_max_connections
extra_port
² thread pool功能的扩展,允许使用额外端口和线程作为管理员救命用
innodb_kill_idle_transaction
² 0(不启用)/N秒,干掉超过N秒的事务(不光是只读查询)
innodb_log_block_size
² 默认512字节,可以调整成4K,以适应SSD设备,提高IO性能
innodb_show_locks_held
² 在SHOW INNODB STATUS中显式多少个锁信息
innodb_show_verbose_locks
² 0/1,是否在SHOW INNODB STATUS中显式更多锁相关的信息
log_slow_filter
² slowlog过滤器,哪些类型的slowlog不记录
log_slow_rate_limit
² 1 ~ 1000,和log_slow_rate_type结合起来用。记录每 1/N次slowlog,不全记录
log_slow_rate_type
² slowlog控制范围是每个session,还是每个query。如果是每个session,需要注意连接池情况下无法生效,并且对复制线程也不生效
log_slow_sp_statements
² 是否记录存储过程产生的slowlog
log_slow_verbosity
² 设置slowlog中,哪些类型的信息要被记录下来,一般设置为full
max_binlog_files
² 至多保留多少个binlog文件
slow_query_log_timestamp_always
² 每次slowlog中,是否总是记录时间戳
thread_statistics
userstat
² 和thread_statistics一起,设置是否统计每个user和thread的信息,存储在information_schema的几个表中

CLIENT_STATISTICS
INDEX_STATISTICS
TABLE_STATISTICS
THREAD_STATISTICS
USER_STATISTICS
slow_query_log_timestamp_precision
slow_query_log_use_global_control
Innodb_deadlocks
Innodb_max_trx_id
Innodb_purge_trx_id
Innodb_s_lock_os_waits
Innodb_s_lock_spin_rounds
Innodb_s_lock_spin_waits
Innodb_x_lock_os_waits
Innodb_x_lock_spin_rounds
Innodb_x_lock_spin_waits

【重要】如果需要TokuDB,那么建议它和MariaDB组合使用

posted @ 2019-04-09 17:56  春困秋乏夏打盹  阅读(250)  评论(0编辑  收藏  举报