MySQL中的死锁
死锁是指两个或两个以上的进程在执行过程中，因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁。 如何查看死锁? 使用命令show engine innodb status查看最近的一次死锁。 InnoDB Lock Monitor打开锁监控，每15s输出一次日志。使用完毕后建议关闭，否则会影响数据库性能。 对待死锁常见的两种策略: 通过innodblockwait_timeout来设置超时时间，一直等待直到超时; 发起死锁检测，发现死锁之后，主动回滚死锁中的某一个事务，让其它事务继续执行。
如何快速定位当前数据库消耗 CPU 最高的 SQL 语句？
1、定位线程 pidstat -t -p <mysqld_pid> 1 2、定位问题sql select * from performance_schema.threads where thread_os_id = xx ; select * from information_schema.`PROCESSLIST` where id=threads.processlist_id 3、查看问题sql执行计划 看一下执行计划基本就可以判断当前数据库CPU为什么消耗这么高了... 原文 https://zhuanlan.zhihu.com/p/462191069 详解博客园 https://www.cnblogs.com/digdeep/p/12775389.html
如果数据库卡住了，CPU百分之几百，处理思路是什么?
(1）多实例的服务器，先top查看是那一个进程占用CPU多 (2）show processlist 查看线程是否有锁住 （3）查看慢查询，找出执行时间长的sql，explain分析sql是否走索引，sql优化 （4）再查看是否缓存失效引起
Mysql 从库比主库多数据了，分析下原因？
innodb_flush_log_at_trx_commit 设置为1时，commit 完成必然写入了硬盘。如果为了提升性能改为了0或2，那么数据库或系统故障时是有可能丢失1s数据的。1s有多少数据很难估算，如果业务繁忙可能是上千，上万或更多。 双1 的另一个参数sync_binlog对应的则是事务数，为了数据安全我们通常也设定为1，但是如果为了提升主库性能并且要保证从库复制的正常，我们可能会考虑改大该值，1000，2000 或更多，相应的从库也有丢失这么多数据的可能。 这样，如果参数innodb_flush_log_at_trx_commit设置为0, sync_binlog 设置为2000. 系统崩溃前的最后1s内执行了7000条插入。那么可能遇到的情况就是主库丢失了7000条数据，而从库只丢失了1000条数据。虽然每条数据主库都自动提交了，但是主库却还没来得及把redo log buffer中的内容刷入到硬盘，系统就崩了，重启后内存数据自然全部丢失，而binlog cache中的数据则每2000条就刷一次到硬盘，所以只损失了最后1000条。
此间事了，那我们再思考下。 1.异步复制为什么存在丢失数据的风险？ 2.半同步复制after_commit 后为什么又推出增强的半同步复制 after_sync？ 3.半同步复制after_commit 在什么情况下会丢失数据？ 4.半同步复制after_sync 能保证不丢失数据吗？ 扩展 1.异步复制 主库发出commit命令，通知从库dump线程获取binlog日志，然后主库完成提交，不关心从库是否取了日志。 所以从库有没有获取到binlog，没人知道。 2.半同步复制-after_commit 主库发出commit，通知从库dump线程获取binlog日志，主库后台完成提交，但当前会话需等待从库接收完日志返回ACK（其他会话可以看到已变更的数据，但当前会话不能做任何操作，尚需等待ACK返回）。从库返回ACK则当前会话完成提交返回操作符。 可能的问题：从库还没写或没接收完binlog主从就异常了。但主库后台已经完成了提交。主库比从库多数据（主库已提交，从库缺失binlog）。 3.半同步复制-after_sync 主库发出commit，同时通知从库dump线程获取binlog日志，主库等待从库接收完日志返回ACK，从库返回则主库完成提交返回操作符，否则继续等待。 从库没写完，主库不会完成提交，所以主库不可能比从库多数据。但是极端情况下可能出现从库完成了binlog落盘，返回ACK给主库的时候主从异常了。导致的问题：从库比主库多数据（从库已接收binlog，但主库没得到ACK，所以没提交，事务进行了回滚。）这时可能导致的问题：1.从库比主库多数据；2.主库重新提交时，从库发生数据冲突。 3不能完全保证数据不丢失后，但3出现的概率要比2小得多 业务繁忙或遇到大事务的情况下，每秒可能产生几十、几百兆或更多的binlog，主从同步过程中，网络慢或从库写磁盘慢，都可能导致binlog在从库的落盘有延迟，这时候遇到数据库故障或系统故障，在2下很容易丢失binlog。 而在3下，无论从库写binlog多慢，主库都要等从库写完才能提交。从库写完后只需返回一个ACK确认消息，传输的内容就小的多了，出问题概率极小。除非网络IO撑满，ACK都接收不了。 原文链接：https://blog.csdn.net/promiseonly/article/details/122539273
MySQL数据库主从数据对比及修复
从库比主库数据多，需要用pt工具对比和修复 原文 https://www.modb.pro/db/101878
mysqI聚簇和非聚簇索引的区别是什么?
mysql的索引类型跟存储引擎是相关的，innodb存储引擎数据文件跟索引文件全部放在ibd文件中，而myisam的数据文件放在myd文件中，索引放在myi文件中，其实区分聚簇索引和非聚簇索引非常简单，只要判断数据踉索引是否存储在一起就可以了。 innodb存储引擎在进行数据插入的时候，数据必须要跟索引放在一起，如果有主键就使用主键，没有主键就使用唯一键，没有唯一键就使用6字节的rowid，因此跟数据绑定在一起的就是聚簇索引，而为了避免数据冗余存储，其他的索引的叶子节点中存储的都是聚簇索引的key值，因此innodb中既有聚簇索引也有非聚簇索引，而myisam中只有非聚簇索引.
mysql性能指标
1. TPS（Transaction Per Second） 每秒事务数，即数据库每秒执行的事务数。 Com_commit ：表示提交次数，通过命令 show global status like 'Com_commit'; 获取； Com_rollback：表示回滚次数，通过命令 show global status like 'Com_rollback'; 获取。 2. QPS（Query Per Second） 每秒请求次数，也就是数据库每秒执行的 SQL 数量，包含 INSERT、SELECT、UPDATE、DELETE 等。 可以通过 show status like 'queries'; 查询得出 。 3. IOPS（Input/Output Operations per Second） 每秒处理的 I/O 请求次数。 可以使用 iostat 命令，查看磁盘的 IOPS，命令如下： yum install sysstat iostat -dx 1 10 原文链接https://www.bilibili.com/read/cv14348610 MySQL 性能指标优化 & 分布式
你们这些服务业务是怎么监控的？/你们mysql主要监控什么？
mysql监控的关键 1.硬件：CPU,内存,磁盘,raid, 2.端口，线程 3.URL 4.业务：select,insert,update,delete # 执行频率和数量 5.慢查询 6.主从复制及延迟复制 延迟； 1.second_behind_master 秒数 2.其他方案(主库写时间戳,从库读取和本地时间比较) 3.按照binlog位置和relay-log位置对比主从偏移量.
Zabbix数据库监控项目: 1）物理层 1.硬件:CPU,MEM,DISK,RAID,CPU温度 2）传输层 1.端口/进程 3）应用层 1.http/https URL(开发写调用数据库的URL) 2.深度URL,调用应用程序所有接口以及所有应用 4)MySQL业务: select,insert,update,delete #执行频率和数量 吞吐量；接收和发送的字节数 下面命令结果: show global status\G #可以查询执行频率和数量 5)innodb引擎层 show engine innodb status\G 6）sql慢查询 当次select语句执行时间*日/小时总数量=总时间监控(前5监控) mysqlslow,mysqlsla,pt---，ELK慢查询日志收集，然后在分析和展示。 7)主从复制及复制延迟 主从： YES YES 延迟； 1.second_behind_master 秒数 2.其他方案(主库写时间戳,从库读取和本地时间比较) 3.按照binlog位置和relay-log位置对比主从偏移量.
mysql如何优化? SQL语句优化?
1 比如说硬件上，尽可能选择固态盘，选择raid10，从库可以选择raid5。服务器BIOS调整，关闭numa设置等等 2 然后操作系统呢不要用swap，不要用lvm，不要用软raid等等，文件系统优化 使用XFS，sas使用deadline调度算法，如果是ssd使用noop调度算法，挂载的时候不记录时间戳 3 内核参数优化 比如swappiness调小一点，尽量不使用swap分区，以及fin超时参数和syn半连接池都调小一点，timi-wait数量的参数调大一点，连接的重用改为1，连接的再循环改为1。也可以适当优化下套接字缓冲区，TCP相关的buffer，网卡的buffer等等 4 mysql配置的优化，比如wait_timeout调整，并发连接数调大一点，把慢查询的一些参数打开，比如超过1秒的，不走索引的，返回结果集大于多少的都记录起来。 5 然后binlog优化 采用行模式，使用双一，还可以自动清除等等 6 存储引擎层，使用双一，数据和索引的缓存buffer_pool 和 日志缓冲区log_buffer都调大一些 7 复制开启gtid主从复制，从库只读 8 索引的优化，用explain测试索引，尽量采用联合索引。 sql语句优化，分为两种，比如日常记录慢查询，然后通过ELK收集分析展示，不断的进行优化。临时慢了的话看CPU和响应的线程，找出SQL语句，再创建索引进行优化 9 集群的优化 a 主从复制至少一主三从，binlog采用row模式，尽量不要跨机房同步（尽量远程写本地读）。 b 业务拆分：搜索功能，like '%老男孩%'，一般不要用MySQL数据库。 c 业务拆分：某些业务应用使用nosql持久化存储，例如：redis。 粉丝关注，好友关系等等,甚至选择Mongodb。 d 数据库前端必须要加redis，用户登录，商品查询。 e 将数据库的数据静态化。 f 数据库集群与读写分离。一主多从。 10 高可用架构：MHA＋Proxysql+GTID 11 数据安全：授权不要用%，开启只读参数，修改php.ini参数 防SQL注入 开启从库只读参数 等等
1.硬件选择: 都要大一些,CPU,内存 硬盘固态,RAID10,如果数据量特别大(TB),SAS. 2.操作系统: 不使用swap,lvm,软raid.bios优化等等我就不说了. 调一下文件系统和IO调度算法 早期要调,C7 xfs,IO调度算法;sas deadline,ssd noop. 挂载优化,不记录时间戳等参数 3.内核参数优化 调节一些常用参数,比如swappiness,避免占用虚拟内存 以及fin超时参数,syn半连接池,还有很多的. timi-wait参数 #优化系统套接字缓冲区/TCP接收/发送缓冲区 #网络设备接收队列 4.mysql配置优化 ## 4.1 连接层 max_connections=3000 #***** wait_timeout=600 #***** ## 4.2 Server层 #慢查询优化 slow_query_log =ON slow_query_log_file =/data/3307/slow.log # ***** long_query_time =1 # ***** log_queries_not_using_indexes =ON # ***** log_throttle_queries_not_using_indexes = 10 # ***** ###binlog优化 binlog_expire_logs_seconds =2592000 # ***** sync_binlog =1 # ***** log-bin =/data/3307/mysql-bin binlog_format =ROW # ***** ## 4.3 存储引擎层 innodb_flush_log_at_trx_commit =1 # ***** innodb_buffer_pool_size =64G # ***** innodb_log_buffer_size =64M # ***** ## 4.4 复制 gtid_mode =ON enforce_gtid_consistency =ON log_replica_updates =ON read_only =ON super_read_only =ON ## 5.索引和SQL语句的优化（老男孩运维班）***** MySQL索引与SQL语句优化（下）老男孩Linux 密码保护 https://www.cnblogs.com/oldboy666/protected/p/15699957.html ##6.网站集群架构上优化 a 主从复制至少一主三从，binlog采用row模式，尽量不要跨机房同步（尽量远程写本地读）。 b 业务拆分：搜索功能，like '%老男孩%'，一般不要用MySQL数据库。 c 业务拆分：某些业务应用使用nosql持久化存储，例如：redis。 粉丝关注，好友关系等等,甚至选择Mongodb。 d 数据库前端必须要加redis，用户登录，商品查询。 e 将数据库的数据静态化。 f 数据库集群与读写分离。一主多从。 通过程序或者dbproxy/proxysql,mysql-proxy,ambea,atlas进行集群读写分离。 g 选择从库进行备份,后台,统计,定时任务,单独使用一个从库。 ##7.高可用架构： MHA+程序读写分离+GTID ####推荐 MHA+Proxysql+GTID ####推荐 ##8.数据库安全优化 老男孩教育MySQL基础安全 1、授权用户对应的主机不要只用%(172.16.1.%)。权限不要给all，最小化授权， 从库只给select。 2、开启只读参数/etc/my.cnf read_only =ON super_read_only =ON 3、防SQL注入（WEB） php.ini更改参数 waf控制（http://blog.oldboyedu.com/nginx-waf/）
磁盘的冗余阵列
事物的隔离级别
隔离级别： # RU ： READ-UNCOMMITTED 读未提交 ------------脏读 可读到事务未提交的数据。隔离性差，会出现脏读（当前内存读），不可重复读，幻读问题 # RC ： READ-COMMITTED 读已提交（可以用） ------------不可重复读 可读到事务已提交的数据。隔离性一般，不会出现脏读问题，但是会出现不可重复读，幻读问题 # RR ： REPEATABLE-READ 可重复读（默认） 防止脏读（当前内存读），防止不可重复读，会出现幻读问题 # SR ： SERIALIZABLE 可串行化 结论： 隔离性越高，事务的并发度就越差。 MySQL事务隔离级别及对应读情况 事务隔离级别 脏读 不可重复读 幻读 读未提交（read-uncommitted） 是 是 是 读已提交（read-committed） 否 是 是 可重复读（repeatable-read） 否 否 是 串行化（serializable） 否 否 否
如何做mha高可用
1.配置各节点的互信 验证 2.安装mha软件,所有节点安装node软件和依赖,管理节点安装manager软件和依赖 3.在主库创建mha需要的用户 4.在管理节点配置好配置文件,创建好配置文件中所需的目录 5.在管理节点进行互信,主从状态检查 6.检查没有问题后 启动mha 7.查看mha的运行状态
主从复制原理 延迟同步 实时同步（半同步复制）
主从复制原理 1 主库开启binlog 2 从库的IO线程负责和主库的binlog dump 线程沟通，要主库的binlog 3 从库的IO线程把拿过来的binlog放到中继日志里 4 然后SQL线程读取中继日志，写入数据库 5. master.info存放连接主库的信息（ip、port、user、password、已经获取的binlog位置点） 5.7以前是磁盘文件。5.7以后在表中 6. relay-log.info存储SQL线程回放过的日志信息。
回表流程
通过辅助索引查询到数据ID，再拿着ID去聚簇索引结构查询的过程叫回表
索引原理
聚簇索引 叶子节点 :1）物理上数据尽可能是连续的： 物理上数据库的区的一兆一兆空间聚合到一起形成索引结构。 且在一个区内数据在磁盘上是连续的，插入的时候按照页顺序存储。 不同区在物理上可能不连续。 每个页内都是逻辑上有序的行。 2）逻辑上尽可能连续 叫聚簇索引组织表（IOT），存数据时，已经是按照主键ID列有序存储数据到各个连续的数据页中。 3）表的数据存储结构就是索引结构的叶子节点. 枝节点 :存储叶子节点中ID范围+指针，如果是B+TREE，叶子节点和枝节点都有双向指针. 根节点 : 存储枝节点的ID范围+指向枝节点的指针
辅助索引 叶子节点 : 将对应列的值+ID列提取出来，按照列值从小到大排序 (按字符排序)，存储到各个page中，生成叶子节点。 枝节点 : 存储了叶子节点中辅助索引列的范围+指针(指向叶子节点的指针). 根节点 : 枝节点的辅助索引列的范围+指针(指向枝节点的指针)
数据库的三范式
第一范式:每个列都不可以再拆分。 第二范式:在第一范式的基础上，非主键列完全依赖于主键，而不能是依赖于主键的一部分。 第三范式:在第二范式的基础上，非主键列只依赖于主键，不依赖于其他非主键。 在设计数据库结构的时候，要尽量遵守三范式，如果不遵守，必须有足够的理由。比如性能。事实上我们经常会为了性能而妥协数据库的设计。
遇到哪些故障，如何排查
主从复制方面的
企业故障案例:面试题:mysql Sleep线程过多?怎么解决?
1）什么是sleep线程？
sleep线程长时间保持客户端与服务端的连接状态
2）导致sleep过多的原因：
1.使用太多持久连接（高并发系统中 不适合使用持久连接），c3p0连接池技术。
2.程序中 没有及时关闭链接。
3.数据库优化不完善 导致执行sql语句过慢
3）解决方法： 这两个参数给它调小点，默认值是28800秒
1、vim /etc/my.cnf 配置文件里进行配置 下次需从启服务器的时候直接生效
想当时就生效利用直接在数据库里设置
interactive_timeout = 120 #交互超时参数 #<==此参数设置后wait_timeout自动生效。
wait_timeout = 120 #设置MySQL的睡眠连接秒数 系统默认是8小时
=================================================
set global wait_timeout = 120 全局生效
set global interactive_timeout = 120
2、和开发沟通,查看代码中没有关闭的连接,及时关闭.
3、及时优化慢查询语句
redis怎么实现持久化
rdb：基于快照持久化，速度更快，一般用作备份，redis的主从复制也是依赖于rdb持久化功能 aof：以追加方式记录redis操作日志的文件。可以最大程度的保证redis数据安全，类似于mysql的binlog。
事务的特性聊一下
A: 原子性 不可分割 # 执行事务的时候，要么全成功要么全失败，保证了原子性 C：一致性 事务发生前中后，数据都最终保持一致。 # DWB + CR 保证事务的一致性 I：隔离性 # 事务操作数据行的时候，不会受到其他事务的影响。 # MVCC保证了事务的隔离性 D: 持久性 # 事务一但提交，永久生效（落盘）,不能再撤销。
网站打开很慢什么原因？
1.很大可能是数据库问题，现场慢的话先看下系统负载，IO，CPU，一般SQL语句慢这几项都会高。 2.然后登陆数据库每秒执行show processlist查看正在执行的SQL语句，找到慢查询语句，可以杀掉一些select语句，如果杀掉是inster或update可能会丢数据，所以先判断是什么样的库，重不重要。 3.然后使用explain抓取慢语句的执行情况，根据返回的结果，对需要建索引的列（where后的条件列、多表连接的列、分组、排序列）建立索引，并核查创建索引效果。 生产场景中，高峰期尽量不要在大表上建立索引。
站在生产的角度给你2台服务器，你怎样搭建?
每台机器双实例，一主3从，proxysql读写分离，不用mha
mysql有关权限表都有哪几个
MySQL服务器通过权限表来控制用户对数据库的访问，权限表存放在mysql数据库里，由mysql_install_db脚本初始化。这些权限表分别user，db, table_priv，columns_priv和host。下面分别介绍一下这些表的结构和内容: user权限表:记录允许连接到服务器的用户帐号信息，里面的权限是全局级的。 db权限表:记录各个帐号在各个数据库上的操作权限。 table_priv权限表:记录数据表级的操作权限。 columns_priv权限表:记录数据列级的操作权限。 host权限表:配合db权限表对给定主机上数据库级操作权限作更细致的控制。这个权限表不受GRANT和REVOKE语句的影响。
有一个情况，大量并发，有慢查询语句，慢查询日志中还没记录，怎么把最慢的三个慢查询语句筛选出来
select * from information_schema.processlist where info is not null order by time desc limit 3;
真实场景1
1.Mysql体系和工作原理 2.Mysql有几种索引 3.B+tree索引原理 4.Mysql的复制流程和原理 5.innodb事务隔离级别 6.解释一下脏读,幻读。
7.Mysqldump实现原理是什么?你们是用什么备份的?
9.内链接。外链接的区别。 10.事物的四大特性是什么? 11.drop，delete的区别是什么? 12.你做过什么优化或者处理过什么有成就感的问题? 13.你在工作当中sql语句改写做的多吗? 14.你在工作当中出的最大的mysql的问题是什么?
真实场景2
1.上家公司负责什么
数据库维护和故障处理，检查数据库运行状态，保障业务正常运行 配合研发进行schema设计及，日常SQL审核及优化 分析业务日常生活中数据库查询慢的问题，进行索引优化 负责数据库实例配置管理、用户安全管理 检查日常备份可用性，定期进行恢复演练 负责高可用监控，故障处理及主从延迟解决 主从复制架构的设计，实施、故障监控、延时分析及处理
2.上家公司遇到过哪些问题，如何解决的
网站突然打开很慢 1.很大可能是数据库问题，现场慢的话先看下系统负载，IO，CPU，一般SQL语句慢这几项都会高。 2.然后登陆数据库每秒执行show processlist查看正在执行的SQL语句，找到慢查询语句，可以杀掉一些select语句，如果杀掉是inster或update可能会丢数据，所以先判断是什么样的库，重不重要。 3.然后使用explain抓取慢语句的执行情况，根据返回的结果，对需要建索引的列（where后的条件列、多表连接的列、分组、排序列）建立索引，并核查创建索引效果。 生产场景中，高峰期尽量不要在大表上建立索引。
sleep线程过多
seleep线程过多
企业故障案例:面试题:mysql Sleep线程过多?怎么解决?
1）什么是sleep线程？
sleep线程长时间保持客户端与服务端的连接状态
2）导致sleep过多的原因：
1.使用太多持久连接（高并发系统中 不适合使用持久连接），c3p0连接池技术。
2.程序中 没有及时关闭链接。
3.数据库优化不完善 导致执行sql语句过慢
3）解决方法： 这两个参数给它调小点，默认值是28800秒
1、vim /etc/my.cnf 配置文件里进行配置 下次需从启服务器的时候直接生效
想当时就生效利用直接在数据库里设置
interactive_timeout = 120 #交互超时参数 #<==此参数设置后wait_timeout自动生效。
wait_timeout = 120 #设置MySQL的睡眠连接秒数 系统默认是8小时
=================================================
set global wait_timeout = 120 全局生效
set global interactive_timeout = 120
2、和开发沟通,查看代码中没有关闭的连接,及时关闭.
3、及时优化慢查询语句
3.造成主从复制延迟的原因
1 硬件差异，服务器配置不一样 2 资源耗尽，执行较大的SQL语句(全表扫描，锁问题，大事务，存储过程) 3 网络问题，不在一个局域网内，公网复制就会产生延迟 4 主库IO串行工作 5 从库单个SQL线程。（5.6的多SQL线程只能按照库级别并发，5.7开始增强多了，可以按照事务级别并发，都依赖于DTID功能） 延迟监控： 1 通过show slave status 看behind master延迟秒数 2 主库写时间戳到一个表里，从库读出来和当前时间对比（更科学的办法）
5.redolog binlog区别
1.redo log是InnoDB引擎特有的; binlog是MySQL的Server层实现的，所有引擎都可以使用; 2.redo log是物理日志，记录的是"在某个数据页上做了什么修改"; binlog是逻辑日志，记录的是这个语句的原始逻辑，比如“给ID=2这的c字段加1”; 3.redo log是循环写的，空间固定会用完; binlog是可以追加写的。“追加写"是指binlog文件写到定大小后会切换到下个，并不会覆盖以前的日志; 4. binlog可以作为恢复数据使用，主从复制搭建，redo log作为异常宕机或者介质故障后的数据恢复使用;
6.binlog会记录查询操作吗？
不会记录，binlog以事件形式记录了所有的DDL和DML语句（除了数据查询语句select）
binlog用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。binlog是mysql的逻辑日志，并且由Server层进行记录，使用任何存储引擎的mysql数据库都会记录binlog日志。 逻辑日志：可以简单理解为记录的就是sql语句。 物理日志：因为mysql数据最终是保存在数据页中的，物理日志记录的就是数据页变更。 binlog是通过追加的方式进行写入的，可以通过max_binlog_size参数设置每个binlog文件的大小，当文件大小达到给定值之后，会生成新的文件来保存日志。 在实际应用中，binlog的主要使用场景有两个，分别是主从复制和数据恢复。 主从复制：在Master端开启binlog，然后将binlog发送到各个Slave端，Slave端重放binlog从而达到主从数据一致。 数据恢复：通过使用mysqlbinlog工具来恢复数据。 对于InnoDB存储引擎而言，只有在事务提交时才会记录biglog，此时记录还在内存中，那么biglog是什么时候刷到磁盘中的呢？mysql通过sync_binlog参数控制biglog的刷盘时机，取值范围是0-N： 0：不去强制要求，由系统自行判断何时写入磁盘； 1：每次commit的时候都要将binlog写入磁盘； N：每N个事务，才会将binlog写入磁盘。 ———————————————— 原文链接：https://blog.csdn.net/zs18753479279/article/details/119964407
7.网络问题如何排查
8.sql语句执行时间变长原因
9.delect 删除数据，数据量还是原先的量，这是为什么？
10.如何排查锁
11.MySQL半同步和增强半同步区别
半同步 和 增强半同步的不同是，等待ACK时间不同，半同步等待ACK的点是Commit之后，此时Master已经完成数据变更。增强半同步等待ACK的点是提交Commit之前
半同步复制 Master处理事务过程中，提交完事务后，必须等至少一个Slave将收到的binlog写入relay log返回ack才能继续执行处理用户的事务。 rpl_semi_sync_master_wait_point = AFTER_COMMIT （什么时间点开始等ack）【这里MySQL 5.5并没有这个配置，MySQL5.7 为了解决半同步的问题而设置的，下文有讲解】 rpl_semi_sync_master_wait_for_slave_count = 1 （最低必须收到多少个slave的ack） rpl_semi_sync_master_timeout = 100（等待ack的超时时间） 问题： 一旦Ack超时，将退化为异步复制模式，那么异步复制的问题也将发送 性能下降，增多至少一个RTT时间 数据不一致性问题，因为等待ACK的点是Commit之后，此时Master已经完成数据变更，用户已经可以看到最新数据，当Binlog还未同步到Slave时，如果发生主从切换，那么此时从库是没有这个最新数据的，用户又看到老数据。
增强半同步和半同步不同是，等待ACK时间不同 rpl_semi_sync_master_wait_point = AFTER_SYNC（唯一区别） 半同步的问题是因为等待ACK的点是Commit之后，此时Master已经完成数据变更，用户已经可以看到最新数据，当Binlog还未同步到Slave时，发生主从切换，那么此时从库是没有这个最新数据的，用户又看到老数据。 增强半同步将等待ACK的点放在提交Commit之前，此时数据还未被提交，外界看不到数据变更，此时如果发送主从切换，新库依然还是老数据，不存在数据不一致的问题。 原文链接：https://blog.csdn.net/qq_33330687/article/details/107496954
1.内存高，cpu不高，是什么原因导致的
内存高是应用程序占内存比较大，比如说参数设置的不合理，比如dbbuffer设置的过大，线程buffer设置的过大，比如说sortbuffer，joinbuffer，这些都是线程buffer。SQL线程比较多的时候，线程buffer是要乘以这个SQL语句的个数的，所以有的时候内存就会占用的比较多，主要是mysql参数设置的要合理一些，内存就不会过高。 Cpu高是运算高，不断的读取磁盘,io就高。
2.压测过程中，大概2-3分钟出现基增的情况从5%到90%又过了大概2-3分钟整体cpu恢复正常了，期间压测没有停过这种情况怎么分析
刚开始压测激增那是正常的，因为没有缓存，等压测时间长了，因为它在buffer里面有缓冲数据了，所以这时候压测就会正常了。 数据库就这种东西，一开始它的buffer没有数据，没有热数据，所以刚开始cpu高,等有热数据了，它就恢复正常了。
3.跟上2条结合：相同的语句同样的条件同样去执行，他又不慢了，怎么分析？
一个情况就是有没有缓存，如果有缓存的话，多执行就会不慢了。 还有一种情况就是由于是并发这个压测嘛，它就会产生锁呀，锁等待呀，这种情况下就会慢，所以当没有锁等待的时候，没有其他数据，没有被其他SQL语句更新的时候，这个查询就不慢了。 所以查询慢，一个是你的查询语句有没有buffer，第二个是有没有锁等待及相关的问题导致。
这三个问题，第一个就是缓冲区，一定要记住缓冲区 热数据有没有缓存，第二个问题就是有没有锁，你这个查询对吧，别的数据，如果是产生一些排它锁呀，这种现象你的查询就查不到，所以其他数据没有被锁的情况下，你的查询就可以。所以一个是缓冲，一个是锁的问题，前三条。
4.如何解决数据库迁移之后变慢的问题
参考：https://blog.csdn.net/weixin_35531779/article/details/113192925
5.现在有这样一个场景,有个业务初始有500G数据每个月增量100G你有什么建议给到开发
6.rc rr 的实现基于什么锁?
7.现在这有一个语句阻塞了,我怎么去找到造成阻塞的语句
8.通过shell怎么把行数据转换为列
9.查询redis的时候语句超时了，怎么排查
726
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
