mysql8.0的坑 - data_locks导致的全库变慢问题

关于mysql常规优化，我们一般会使用工具对slowlog汇总分析后，优化重点SQL。 在使用过程中，有一些细节问题，在此记录： 1. SQL始终没有记录到slowlog中？ 2. 一条慢SQL的开始和结束时间？ 3. 错误的SQL是否会被记录？ 4. 中断的SQL是否会被记录？ 5. Rows_exmained的含义？

覆盖索引是一种常用的SQL优化手段，可以减去回表的开销，以提高SQL效率。对于同一个SQL，覆盖索引性能一定比非覆盖索引高吗？

业务反馈mysql无法访问，随即show processlist查看，发现存在大量Waiting for table flush的select sql线程。找到阻塞源并kill后，业务恢复正常。阻塞源是一个running状态的select sql，已经运行了20个小时，还未执行完成。理论上select sql之间是不会阻塞的，可本例又是如何产生的呢？

有一个简单需求：用mysqldump在线备份主库，使用基于GTID方式重建从库。当在从库初始化数据后，数据同步出现不一致现象，随即排查，思路如下：。从库初始化@@GLOBAL.GTID_PURGED时，是否正确？检查后发现，是由于mysqldump存在bug导致。

还有使用触发器也可以。不过，个人建议第一种，在SELECT时使用函数即可。其它的方案会浪费存储空间，且保存数据时多做一些操作。

备份举例：全库备份：产生文件F差异备份（基于上一次的全库备份）：备份过2次，产生文件D1，D2日志备份（基于上一次的日志备份）：备份过3次，产生文件L1，L2，L3还原举例：F+(L1+L2+L3)F+D1+(L1/L2/L3)F+D2+(L1/L2/L3)你的问题：答案是肯定的。只要相关备份文件都在列表中，sql server会自动判断全备、差备和日志备份，恢复到指定的时间点。

子查询优化：https://developer.aliyun.com/article/711481?spm=5176.24320532.content1.1.696a6e3dWS8bLs

1. 首先，确保已经连接到了mysql。比如使用一个新账号进行这个操作2. “卡”着说明可能有阻塞，一般会查是行级别锁(innodb_trx)，还是表级别锁(meta_lock或show engine innodb status)，还是其它阻塞?3. 也许并没有“卡”着，只是慢或事务很大而已，你要知道“卡”在哪条SQL上了(processlist)?如果没有锁，是否磁盘满了，查错误日志等。不过，只

1. 按实际分配2. 文件中的页和BUFFER POOL中的页一一对应3. 每个连接是有私有内存，但数据页的加载是放到BUFFER POOL中的https://help.aliyun.com/document_detail/51799.html

关系型数据库的表本身就是N维数组，所以不提供“数组”功能。

清理执行计划缓存。 对比表：是否启用压缩，索引是否一样 统计信息：可以手工收集下统计信息 如果还不行，加索引提示是否可生成一样的执行计划？ 如果还不行，继续找原因，肯定有不一样的地方。

可以粗略统计表或库级别数据量，两次收集，求差。select table_schema, table_name, engine, table_type, sum(table_rows) as rows, round(sum(data_length)/1024/1024, 2) as `data(MB)`, round(sum(index_length)/1024/1024, 2) as `index

1、随机写的性能raid10要比raid5好很多        2、同时读写的读性能raid10要比raid5好一些3、raid10或者raid5，顺序读写没有明显的差异，随机读写、同时读写两倍左右的差别4、数据库业务，建议raid10，无论是性能还是容错。不差钱，肯定raid10。

会。会。ldf日志会记录下数据库所有的变化，数据和索引页的更改都会被记录。数据库的崩溃恢复，镜像，复制等功能全部依靠ldf文件。

是指\n吧？如果字段值中包含了换行符，因为它不可见，所以导出后会用\n表示，等到再导入到其它系统时，也会正确识别\n为换行符。

先把数据库设置为“简单”模式，再收缩事务日志文件，再恢复“完整”模式，不知道出于什么原因，要这样来收缩事务日志文件？正确的操作是：数据库设置为“完整”模式根据事务日志产生的量，定时备份事务日志文件，已备份的事务日志空间会被重用。如果特殊情况下，事务日志文件备份后无法重用，且文件大小很大，才考虑用你JOB中的方式处理。

是的，有可能。你可以查下当shirk操作失败时，sql server正在做什么操作，然后测试下。参考：https://www.cnblogs.com/nzperfect/archive/2012/07/24/2606841.html

MogDB是云和恩墨基于openGauss内核进行增强提升，推出的一款安稳易用的企业级关系型数据库,mogha是它的高可用组件。均不开源。

先把数据缓存到N张临时表，再用bcp生成N个csv文件，参考：https://www.cnblogs.com/hawking8su/p/14331942.html

你要查明所谓"占用大量线程，导致全局锁表"的原因：是否多线程备份，谁在持有锁，持有什么锁，谁被阻塞，为什么被阻塞？备份时，主库是否有高并发然后再定解决方案：在业务低峰期备份设置备份超时时长(xtrabckup)；使用特定的备份账号，监控锁信息并及时处理在从库备份

mysql支持自定义函数，可带0-N个参数。 使用时，和系统函数的用法一样。

1. 需要进行过一次完整备份。 2. 进行日志备份后，才能收缩。 3. shrink应该可以了。如果还是不行，再进行一次日志备份，应该就可以了。 4. 如果还不行，查看日志空闲空间，寻求其它方案：比如先改成简单模式，问题解决后再改回来。

MySQL update ... where in(...) 为什么不走索引？

select * from tb where field=chr(0);oracle确实存在这个问题，参考：https://www.modb.pro/db/33720

测试了下，SQL执行时长，只要超过slowlog的阈值(long_query_time)，即使最终执行失败，也会记录。

没明白你说的意思。事务执行出错时，根据情况，可能事务会回滚，也可能不会回滚，不能忽略。一般来说，客户端要有事务异常捕获和处理机制。

selectuser, db, substring_index(host,’:’,1) as host, count(*) as cntfrom information_schema.processlistgroup by user, db, substring_index(host,’:’,1)order by user, db, host;

设置innodb_fast_shutdown=0, 干净shutdown mysql，备份除mysql程序外的所有文件(log文件除外)，记住你的mysql版本。

方案1：关闭mysql，move datadir整个目录至新磁盘，修改my.cnf中相关路径，启动mysql。方案2：新磁盘创建表空间，新建的表指定存储到这个表空间；或迁移旧表至新表空间，参考：https://blog.51cto.com/u_14150796/5372402一般情况建议方案1，方案2增加运维复杂度。

create index的时候创建了"索引树"(B+Tree)，后续的insert,delete,update会实时更新相应的B+Tree。这样当select时，直接搜索B+Tree即可。还有，像自适哈希索引是innodb根据一定条件自动触发创建的，但都是先创建，再使用。

是的。命令在服务器端执行，运行的结果通过网络传回客户端，并在客户端显示。

历史的锁信息查不到。可以定时抓取当前锁等待信息，保留下来，以备分析。

#mysql5.7+ #会话级别 show variables like '%%'; select * from performance_schema.session_variables; #全局级别 show global variables like '%%'; select * from performance_schema.global_variables;

重新指定字段字符集即可(排序规则默认)CREATE TABLE `t1` ( `id` int(11) NOT NULL AUTO_INCREMENT, `serial_no` varchar(50) CHARACTER SET utf8 COLLATE utf8_unicode_ci NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAU

当我们想了解一个redis时，除了它的软硬件配置、架构，还想知道这个redis中到底存储了什么？占用了多少内存？是否存在bigkey？

定时任务存储在msdb库中，把这个库恢复了，启动sql server代理，就能看到JOB了。一般来说，msdb库也是需要备份的。