【金沙官网线上】MySQL Tips

 

paip.mysql备份慢的解决

MySQL中的一些Tips,个人总结或者整理自网络

 

 

版本5.0.45-community-nt

不明白为什么MySQL的很多材料中总是喜欢把联合(复合)索引和覆盖索引放在一块说事?

主数据库50W数据,备份的sql34M..压缩后5.8m

1,联合索引是一种索引的类型,指创建索引的时候包含了多个字段。
2,覆盖索引是一种查询优化行为,索引结构本身就可以满足查询,无需回表,而不是一种索引。
3,联合索引和覆盖索引并没有任何必然关系,单个字段的索引也有可能会发生覆盖索引的情况。

 


原来备份178 S.. 调整MY.INI  加大10倍...  而个88S... 不压缩的情况下45s

MySQL中的filesort

 

"using filesort" means that the sort can't be performed with an index. 仅此而已,并不一定真的使用文件完成排序。
mysql无法利用索引完成的排序操作成为“文件排序” ,当需要排序,而又无法直接通过索引直接完成排序,需要额外的操作的时候发生using filesort。
金沙官网线上,filesort只能应用在单个表上,如果有多个表的数据需要排序,那么MySQL会先使用using temporary保存临时数据,然后再在临时表上使用filesort进行排序,最后输出结果。

换成个5.6 , 还要中多时间,要不走粤慢兰..


不压缩的情况下43s...  调整MY.INI  加大10倍.  40S.....差距不明显木..

last_query_cost

 

对比MySQL不同写法或者改变了索引对象之后SQL的效率的时候,似乎只能傻傻地看执行时间以及一个粗略的执行计划,呵呵。
IO、CPU、内存使用都看不到,而last_query_cost似乎也不一定靠得住。
last_query_cost的单位也不是page什么的,应该是一个综合代价的值。
The Last_query_cost value can be computed accurately only for simple “flat” queries, not complex queries such as those with subqueries or UNION.
For the latter, the value is set to 0.

最终解决方案:copy备份

至于Profile或者performance_schema.events_stages_history_long 里面的信息,也就是看看sending data,也是一个综合资源消耗的时间结果。



..块啊,7秒搞定..是热备份.不用关机..

Sending Data

 

Profile或者performance_schema.events_stages_history_long 中的Sending data
“Sending data”并不是单纯的发送数据,而是包括“收集 + 发送 数据”,说白了就是查询到结果返回的整个过程,MySQL里很多命名的东西都很有误导性,上面还在说filesort。
而performance_schema.events_stages_history_long中的绝大部分步骤,根本无法改变。
比如closing tables,cleaning up等等,本身就是查询引擎的一部分消耗,跟用户行为无关,用户也无法左右其时间消耗。

参考其他自料儿..

金沙官网线上 1

====================


数据文件大约200GB,平时备份(mysqldump)压缩后的大小大约20GB,正常备份时间在2个小时内。一台服务器上,安装了多个mysql实例

 

 

停止复制

 

  reset slave 只是删除了master.onfo和reply_log.info文件,复制同步信息还在,reset slave all彻底地清除复制。

,这个数据库是其中一个


 

 

mysql按照备份恢复方式分为逻辑备份和物理备份

 慢查询是否记录因阻塞造成超过long_query_time的查询?

 

  经过测试,答案是不会。慢查询在计算“慢”的查询的时候,是只计算正常执行时间超出long_query_time的查询,而不计算阻塞的时间。
  慢查询也不会因为超时或者其他原因造成的失败的查询。

 

  补充:在SQL Server中,类似于用于记录慢查询的trace或者扩展事件,在记录“慢查询”的时候,是会把阻塞时间也算作“慢”之内的。

逻辑备份是备份sql语句,在恢复的时候执行备份的sql语句实现数据库数据的重现


 

 

 

MySQL中的预读

物理备份就是备份数据文件了,比较形象点就是cp下数据文件,但真正备份的时候自然不是的cp这么简单

如果一个extent中的被顺序读取的page超过或者等于该参数变量的,innodb将会异步的将下一个extent读取到buffer pool中,
由参数innodb_read_ahead_threshold来控制
比如该参数的值为30,那么当该extent中有30个pages 被 sequentially的读取,则会触发innodb linear预读,将下一个extent读到内存中。

 


 

 

这2种备份各有优劣,一般来说,物理备份恢复速度比较快,占用空间比较大,逻辑备份速度比较慢,占用空间比较小

 

mysqldump工具备份

未完待续。

 

 

mysqldump由于是mysql自带的备份工具,所以也是最常用的mysql数据库的备份工具。支持基于InnoDB的热备份。但由于是逻辑备份,所以

 

 

速度不是很快,适合备份数据量比较小的场景。

mysqldump完全备份+二进制日志 —>实现时间点恢复

 

 

 

看累挂CFG DEFAULT    show  VARIABLES like '%size%'


 

 

binlog_cache_size 32768

binlog_stmt_cache_size 32768

bulk_insert_buffer_size 8388608

delayed_queue_size 1000

host_cache_size 279

innodb_additional_mem_pool_size 8388608

innodb_buffer_pool_size 134217728

innodb_change_buffer_max_size 25

innodb_ft_cache_size 8000000

innodb_ft_max_token_size 84

innodb_ft_min_token_size 3

innodb_log_buffer_size 8388608

innodb_log_file_size 50331648

innodb_online_alter_log_max_size 134217728

innodb_page_size 16384

innodb_purge_batch_size 300

innodb_sort_buffer_size 1048576

innodb_sync_array_size 1

join_buffer_size 262144

key_buffer_size 8388608

key_cache_block_size 1024

large_page_size 0

max_binlog_cache_size 18446744073709547520

max_binlog_size 1073741824

max_binlog_stmt_cache_size 18446744073709547520

max_heap_table_size 16777216

max_join_size 18446744073709551615

max_relay_log_size 0

metadata_locks_cache_size 1024

myisam_data_pointer_size 6

myisam_max_sort_file_size 2146435072

myisam_mmap_size 4294967295

myisam_sort_buffer_size 8388608

optimizer_trace_max_mem_size 16384

performance_schema_accounts_size 100

performance_schema_digests_size 10000

performance_schema_events_stages_history_long_size  10000

performance_schema_events_stages_history_size  10

performance_schema_events_statements_history_long_size

本文由金沙官网线上发布于数据库,转载请注明出处:【金沙官网线上】MySQL Tips

您可能还会对下面的文章感兴趣: