根据文档整理了一下,写在这里了。
userstat 统计客户端性能问题
information_schema.client_statistics
information_schema.index_statistics
INFORMATION_SCHEMA.THREAD_STATISTICS 涉及参数 thread_statistics
INFORMATION_SCHEMA.USER_STATISTICS 统计到那个用户引起的大负载,估算服务器容量
提供了一些额外的名利用来刷新这些性能视图:
flush table_name (上面的table)
show user_statistics |thread_statistics |...
innodb_lazy_drop_table 对表的删除延后执行bufferpool 的清理工作, innodb_file_per_table =1
正常情况下,执行力drop table后,db会扫描所有的bufferpool 对应于某个表空间所有的内存页
会被清除,如果bufferpool 设置很大,会很浪费时间,并且在扫描期间,是不能处理查询的。
设置这个参数,会标记这些内存块为与数据文件一致,然后只有在系统查找新的空闲内存的块的时候,
才会重用这些数据页。 提升性能。
innodb_doublewrite_file 设置单独的double-write buffer 数据文件,最好是设置在单独的磁盘上,或者ssd盘。
double-write 有一定的性能损失,主要应对数据安全。
query_cache_strip_comments 在query cache 查询结果的时候,忽略sql 语句的中的注释(comment)
这样可以提高命中率。
innodb_overwrite_relay_log_info: percona server 提供了主从复制的恢复机制,如果复制过程中宕机了,在日志文件里会打印已经恢复到日志点,
会覆盖掉slave-rely.info文件的内容。
slave 机器直接从日志中的日志点启动slave 就可以,如果相应的日志还存在,则不需要重新搭建备机。
innodb_recovery_update_relay_log 功能同上,增强的复制功能。
innodb_corrupt_table_action innodb表有时候会损坏,一般情况向,如果遭遇到一个数据库表损坏,那么mysql 会导致自杀,系统崩溃,
设置这个参数,如果设置了innodb_file_per_table ,那么percona 会报警,然后会忽略掉针对这个表的io操作。
或者设置为数据库崩溃。
针对NUMA 的增强: 建议同事设置这3个参数。
innodb_buffer_pool_populate 预先分配内存。mysql启动时候,即根据参数分配完内存。
flush_caches 启动mysql 的时候执行flush cache 清空cache ,便于为上一个参数的预分配内存配合到NUMA
numa_interleave=all mysql 的内存分配策略使用interleave=all 策略。
命令:
SHOW SLAVE STATUS NOLOCK
mysql 如果在slave 上正在执行一个长事务,这个时候,如果我们执行stop slave ,会导致stop slave 命令等待很
长时间才能执行
而如果恰巧这个时候,你开了另一个客户端,执行下show salve status ,那就更悲催了,主要原因是因为mysql 在
复制里使用了一个全局锁。
percona server 增强了这个命令,加上show slave status nolock 命令,这个命令不需要等待锁的获得,可以直接
返回,
但是返回的slave 的状态信息与 show slave status 拿到全局锁后显示的信息有稍许不一致。大不影响判断。
innodb_recovery_stats 这个参数的设置,会强制 xtradb 在数据库启动的时候执行数据库恢复,相关的信息会写在errlog中。
innodb_dict_size_limit 限制innodb 数据字典的尺寸, mysql 中表一旦打开是,就会占用数据字典的尺寸,对于很多表的数据库,
数据字典的尺寸会很庞大,设置参数会限制数据字典的大小,当无法容纳新的数据时,会采用LRU的策略清理字典空间
配套的一个状态参数: innodb_dict_tables ;
来自 “ ITPUB博客 ” ,链接:https://blog.itpub.net/133735/viewspace-752688/
,如需转载,请注明出处,否则将追究法律责任。