写在前面(声明)
声明:这里的各个内容基本都是平时看到的一些觉得有用的文章资讯的链接汇总,里面的内容都不是我的创作!
做个快乐的搬运工!
MySQL
- ubuntu如何卸载mysql(ubuntu卸载mysql的具体方法)
基础原理
- MySQL数据库相关流程图原理图
- 10张图告诉你,MySQL 是如何查找数据的?
- 8张图,5大组件!了解MySQL查询语句执行过程。
- MySQL 架构总览->查询执行流程->SQL 解析顺序
- 顺丰快递:请签收MySQL灵魂十连
- 鸟瞰 MySQL,唬住面试官!
- MySQL面试高频
- MySQL 5.7 vs 8.0,哪个性能更牛?
- 你还在 Docker 中跑 MySQL?恭喜你,可以下岗了!
存储
- mysql 的一行记录是怎么存储的?
- 不要在 MySQL 中使用“utf8”,请使用“utf8mb4”
- 为什么MySQL不推荐使用 UUID 或者雪花id作为主键?
- Mysql的逻辑架构
- Msql的存储引擎
- 必须了解的mysql三大日志-binlog、redo log和undo log
- 能说一说Mysql缓存池吗?
- MySQL每秒50w+的写入,如何实现?
事务和锁
- MySQL 四种隔离级别
- MySQL 事务详解
- 图解MySQL事务底层原理
- 精讲 MySQL 事务日志:redo log 和 undo log
- 讲讲 MySQL 中的 WAL 策略和 CheckPoint 技术
- 57张图,13个实验,干死 MySQL 锁!
索引
- MySQL 索引的分类、何时使用、何时不使用、何时失效?
- MySQL 索引失效的 15 种场景!
- Mysql索引-B+树是如何生长的
- 为什么 MySQL 索引要使用 B+树而不是其它树形结构?比如 B 树?
- 用16张图就给你讲明白MySQL为什么要用B+树做索引!
- 史上最牛分析MySQL索引机制的实现!不接受反驳!
- mysql 的索引有哪几种?
- Mysql使用索引的正确方法及索引原理详解
- 深入剖析 MySQL 索引和 SQL 调优实战
- 关于MySQL索引的9大考点,全包含在这道面试题里了!
SQL相关
基础
- 在工作中常用到的SQL
- 必须了解的十个高级 SQL 概念
- mysql中使用if,case的条件判断的sql语句
- MySQL中between和大于小于的比较
- MySQL + JSON = 王炸!!
- MySQL 中的 distinct 和 group by 哪个效率更高?
优化
- mysql 执行计划
- 一文终结 SQL 子查询优化
- 一条 SQL 语句执行得很慢的原因有哪些?
- 数据量很大,分页查询很慢,四招立马搞定!
- SQL:我为什么慢你心里没数吗?
- mysql 查询优化
- 52 条 SQL 语句性能优化策略
注意事项
- 如何解决MySQL order by limit语句的分页数据重复问题?
- 8 种最坑的 SQL 错误用法,第一个最坑
- 为什么MySQL不建议使用Delete删除数据?
- MySQL 大批量插入,如何过滤掉重复数据?
- 这个 MySQL bug 99% 的人会踩坑!
- Insert into select语句引发的生产事故!
- MySQL 由于 Java 日期 LocalDateTime 数据精度引发的线上问题
- 为什么 MySQL 不推荐使用 join?
分库分表
- 关于数据库的水平切分和垂直切分的一些概念
- 我们为什么要分库分表?
- 出现这 4 种情况,才是考虑分库分表的时候!
- CTO说MySQL单表行数不要超过2000w,为啥?
- 我说MySQL单表超过2000w就要分库分表,面试官让我回去等通知?
- 盘点分库分表中,你一定要避开的那些坑!
- 一次分表踩坑实践的探讨
- 分库分表之后,id 主键如何处理?
- 分库分表?如何做到永不迁移数据和避免热点?
- 256变4096:分库分表扩容如何实现平滑数据迁移?
- 别逗了,你真以为 MySQL 分库分表支持服务无限扩容吗?
- 一种简单易懂的 MyBatis 分库分表方案
主从和高可用
- 高性能Mysql主从架构的复制原理及配置详解
- MySQL 主从,6 分钟带你掌握!
- Mysql主从复制原理
- mysql主从简单配置
- Mysql高可用部署架构
- MySQL 中主库跑太快,从库追不上怎么整?
- 如何解决MySQL主从复制延时问题
- 如何基于 MySQL 主从模式搭建上万并发的系统架构?
一些案例
设计和优化
- 日均7亿交易量,如何设计高可用的MySQL架构?
- 记录一次MySQL两千万数据的大表优化解决过程,提供三种解决方案
- MySQL大表优化方案,单表优化、读写分离、缓存、分区表……都在这里了
- MySQL 调优/优化的 101 个建议!
- 一次业务逻辑优化,竟然解决了MySQL CPU消耗800%的性能问题!
- 高并发场景下的数据库事务调优
- 头疼!百万级 MySQL 的数据量,如何快速完成数据迁移?
问题故障处理
- MySQL 5.6.35 索引优化导致的死锁案例解析
- 删库不跑路,我含泪写下MySQL数据恢复大法……
工具
- 这款 SQL自动检查神器,吊炸天的功能,真TMD多!!
- 简单、易用的 MySQL 官方压测工具,建议收藏!
一些笔记
记录一次因为数据记录过多导致的查询缓慢
背景: 在一次测试环境中发现,某表记录达到百万级别就非常缓慢,当到达200w级别需要几十秒,500w以上时应用查询都超时了(实测查询结果需要200秒左右出结果);
因为基本上大家公认的mysql都可以支持到千万级别的数据量级,所以这个结果明显差距巨大;
后根据在网上查找资料等,得知,这种数据量级,都是硬件足够的前提;
在这个事例中,Mysql的innodb_buffer_pool_size只设置了4G,而当表数据量级上去后,这个内存容量已经不足以存储下所有的索引了;所以查询会非常的慢;
根据这个,当增大innodb_buffer_pool_size后,确实可以明显提升查询速度;查询buff和cache相关sql:
show global variables like '%buffer%'; show global variables like '%cache%'; show status like '%innodb_buffer_pool_%';
查询表容量相关sql:
SELECT engine, count(*) as TABLES, concat(round(sum(table_rows)/1000000,2),'M') rows, concat(round(sum(data_length)/(1024*1024*1024),2),'G') DATA, concat(round(sum(index_length)/(1024*1024*1024),2),'G') idx, concat(round(sum(data_length+index_length)/(1024*1024*1024),2),'G') total_size, round(sum(index_length)/sum(data_length),2) idxfrac FROM information_schema.TABLES WHERE table_schema not in ('mysql', 'performance_schema', 'information_schema') GROUP BY engine ORDER BY sum(data_length+index_length) DESC LIMIT 10;
查询某库下各表相关情况信息:
SELECT TABLE_NAME, DATA_LENGTH, INDEX_LENGTH, ( DATA_LENGTH + INDEX_LENGTH ) AS length, TABLE_ROWS, concat( round( ( DATA_LENGTH + INDEX_LENGTH ) / 1024 / 1024, 3 ), 'MB' ) AS total_size FROM information_schema.TABLES WHERE TABLE_SCHEMA = '数据库名' ORDER BY length DESC;
查看某表详细状况:
show table status like 'xxx表名';
相关参考:
数据库性能优化—MySQL单表最大记录数超过多少时性能会严重下降
mysql性能调优——缓存命中率innodb_buffer_pool_size
INNODB_BUFFER_POOL_SIZE:设置最佳内存值
mysql中内存的使用与分配查询mysql事务和锁
mysql默认的获取锁等待超时时间为50秒;可以通过设置innodb_lock_wait_timeout参数来调整;
#查看连接数,右下角看下有多少条记录 SHOW full PROCESSLIST; #查看mysql配置的最大连接数 show variables like '%max_connections%'; #查看mysql事务和死锁 #当前运行的所有事务 SELECT * FROM information_schema.INNODB_TRX; #当前出现的锁 SELECT * FROM information_schema.INNODB_LOCKs; #锁等待的对应关系 SELECT * FROM information_schema.INNODB_LOCK_waits; #查询产生锁的具体sql select t.trx_id, t.trx_mysql_thread_id, t.trx_query from INFORMATION_SCHEMA.INNODB_LOCKS l, INFORMATION_SCHEMA.innodb_trx t where l.lock_trx_id=t.trx_id; #查询出所有有锁的事务对应的线程ID并组装成kill语句; select concat('KILL ',t.trx_mysql_thread_id ,';') from INFORMATION_SCHEMA.INNODB_LOCKS l,INFORMATION_SCHEMA.innodb_trx t where l.lock_trx_id=t.trx_id; #KILL CONNECTION与不含修改符的KILL一样:它会终止与给定的thread_id有关的连接。KILL QUERY会终止连接当前正在执行的语句,但是会保持连接的原状。KILL命令的语法格式如下: #KILL [CONNECTION | QUERY] thread_id #通过命令开启死锁日志记录到MySQL错误日志中,默认情况是不开启的。 set global innodb_print_all_deadlocks = 1; #MySQL 默认会在 error log 中记录下死锁事件 #查看最近一次死锁情况 show engine innodb status;