性能管理与架构设计

电商双11大促成败关键: 数据库和服务器的稳定

1. 源代码相同, web服务器可以横向扩展, 来保证量大时的稳定性
2. 数据库无法拷贝数据来实现稳定性, 很难保证完整性和一致性

性能指标

• rt, response time, 响应时间
• pv, , 页面被浏览次数
• tps, transactions per second, 每秒内的事务数(包括用户请求服务器, 服务器内部处理, 服务器返回给用户)
• qps, queries per seconds, 每秒查询率, 一台服务器每秒能够响应的查询次数

影响数据库性能因素

1. sql的查询速度(大部分都是由慢查询导致的)
2. 服务器硬件
3. 网卡流量
4. 磁盘IO

大表: 记录行数单表超过千万行, 表数据文件超过10G

1. 慢查询耗时长
2. 建立索引需要很长时间, <5.5建立索引会锁表, >=5.5引起主从延迟

大事务: 区别与其他文件系统的特性, 具有原子性的sql语句; 运行时间长, 操作数据比较多的事务

1. 原子性, 整个事务操作要么全部成功, 要么全部失败
2. 一致性, 事务开始之前或结束后数据库完整性没有被破坏
3. 隔离性, 一个事务对数据库中数据修改后, 在未提交完成前对于其他事务是不可见的; 未提交读, 已提交读, 可重复读, 可串行化

三大范式

1. 1NF, 所有字段都是单一属性, 各个列都是基本数据类型构成, 设计出来是简单的二维表
2. 2NF, 只具有一个业务主键, 不存在非主键列只对部分主键的依赖关系(组合主键才有的情况)
3. 3NF, 非主属性既不部分依赖也不传递依赖于业务主键

SQL性能获取

1. 慢查询日志
2. 1. slow_query_log 启动或停止慢查询日志
   2. 通过脚本定时开关, 实现某段时间开启慢查询
   3. slow_query_log_file 慢查询日志的存储路径及文件
   4. long_query_time 指定记录慢查询日志sql执行时间阀值(默认10s, 记录所有符合条件的sql, 包括回滚的sql)
   5. log_queries_not_using_indexs 是否记录未使用索引的sql
   6. set global xxx=on
3. 实时性能获取
4. 1. information_schema的processlist表

数据库结构优化目的

1. 减少数据冗余, 必要的冗余也是必须的
2. 避免数据维护中出现更新(依赖其它实体), 插入(多行更新)和删除异常(依赖其它实体)
3. 节约数据存储空间
4. 提高查询效率

设计表原则

1. 减少连表操作
2. 减少不必要的冗余