MySQL学习笔记(二)

服务器性能剖析

1、性能指标

1. 基准测试是针对系统设计的一种压力测试。
2. 吞吐量: 单位时间内的事务处理数(TPS)
3. 响应时间或延迟
4. 并发性
5. 可扩展性

SHOW STATUS 和SHOW PROCESSLIST 命令
tcpdump

Schema与数据类型优化

数据类型选择

1. 更小的通常更好，占用更少的磁盘、内存和CPU缓存。
2. 简单就号，占用更少的CPU周期。如整型比字符操作代价更低。
3. 尽量避免NULL。查询中包含NULL列，优化会更困难，索引、索引统计和值都会变的复杂。可为NULL的列会使用更多的存储空间。如果计划在列中建索引，应尽量避免可谓NULL的列。
4. BLOB和TEXT区别在于BLOB存储的是二进制数据，没有排序规则和字符集，而TEXT类型有字符集和排序规。MySQL只对每个列的最前max_sort_length字节做排序。不能将列全部长度做索引，也不能使用这些索引消除排序。如果EXPLAIN执行计划中Extra列包含“Using temporary” 则说明这个查询使用了隐式临时表。

schema设计

1. 不可有太多的列: 存储引擎API工作时需要在服务器层和存储引擎层之间通过行缓冲格式拷贝数据，然后再服务器层将缓冲内容解码成各个列。从行缓冲中将编码过的列转换成行数据结构的操作代价是非常高的。
2. 不可进行太多的关联: 单个查询最好再12个表以内做关联。在设计的时候最好向单表查询靠拢。
3. 进行特定的范式与反范式化的设计
4. 使用缓存表和汇总表
5. 物化视图: 预先计算并存储在磁盘的表，通过各种策略刷新和更新。工具Flexviews，变更数据抓取，可以读取服务器的二进制日志并解析相关行的变更。
   schema设计总结:
   1. 避免过度设计，例如会导致极其复杂的schema设计，或者很多列的表设计
   2. 使用小而简单的适合数据类型，应尽量避免NULL
   3. 尽量使用相同的数据类型存储相似或相关的值，尤其是关联条件中使用的列
   4. 注意可变长字符串，在临时表和排序时可能导致悲观的按最大长度分配内存
   5. 尽量使用整形定义标识列(枚举)
   6. 避免使用MySQL遗弃的特性，如浮点数的精读，或者整数的显示宽度
   7. 小心使用ENUM和SET，最好避免使用BIT

来源：CSDN

作者：kaisnm

链接：https://blog.csdn.net/kaisnm/article/details/103753939