MySQL性能标准
- QPS：Queries Per Second，每秒查询率。执行查询增加。
- TPS：Transactions Per Second，也就是事务数/秒。执行事务增加。
- PV：页面被浏览的次数。打开页面就增加。
- 并发数： 系统同时处理的request/事务数
- 响应时间： 一般取平均响应时间
QPS（TPS）= 并发数/平均响应时间 或者 并发数 = QPS*平均响应时间
例如：某个查询/事务需要0.1s，并发10个，QPS就是10/0.1 = 100，也就是每秒可以处理100个查询/事务。
【峰值QPS和机器计算公式】（来源于网络）
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器
问：每天300w PV 的在单台机器上，这台机器需要多少QPS？
答：( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)
问：如果一台机器的QPS是58，需要几台机器来支持？答：139 / 58 = 3
影响MySQL的方面
- 服务器硬件
- 服务器系统
- 存储引擎
- 参数配置
- 表结构和SQL语句
常见的现象和处理办法
1.大事务
概念：
- 事务特性：原子性，一致性，隔离性，持久性。
- 大事务：运行时间长，操作的数据表。
- 产生的影响：锁多，阻塞超时。回滚时间长。主从延迟。
- 解决方式：避免一次处理太多。一处不必要的查询。
关于隔离性：
- 未提交读：Read unCommited ,带来脏读。
- 已提交读：Read Commite，带来多次查询不一致。
- 可重复读：Pereatable Read，带来一定的延迟。
- 可串行化：serializable，会带来大量的锁表。
- 隔离性越来越高，但是并发性越来越低。一般推荐中间的两种。
2.大表
行数超过千万或者文件大于10G
- 导致主键建立时间过长，DDL
- 版本<5.5 建立索引的时候会锁表
- 版本>5.5 会导致主从延迟。
- 修改表结构：长时间锁表
- 阻塞操作
- 主从延迟
解决办法：
- 分库分表：
- 难点：主键的选择，跨分区查询和统计。
- 历史数据归档：有效解决对业务的影响。
- 难点：归档的时间点，归档操作（删库操作）。
详细的优化会在后面的篇幅分享
网友评论