共计 4463 个字符,预计需要花费 12 分钟才能阅读完成。
什么影响了数据库查询速度
1.1 影响数据库查询速度的四个因素
1.2 风险分析
QPS: QueriesPerSecond
意思是“每秒查询率”,是一台服务器每秒能够相应的查询次数,是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准。
TPS:是 TransactionsPerSecond
的缩写,也就是事务数 / 秒。它是软件测试结果的测量单位。客户机在发送请求时开始计时,收到服务器响应后结束计时,以此来计算使用的时间和完成的事务个数。
Tips:最好不要在主库上数据库备份,大型活动前取消这样的计划。
1、效率低下的 sql
:超高的 QPS
与 TPS
。
2、大量的并发:数据连接数被占满(max_connection
默认 100
,一般把连接数设置得大一些)。
并发量: 同一时刻数据库服务器处理的请求数量
3、超高的 CPU
使用率:CPU
资源耗尽出现宕机。
4、磁盘 IO
:磁盘 IO
性能突然下降、大量消耗磁盘性能的计划任务。
解决:更快磁盘设备、调整计划任务、做好磁盘维护。
1.3 网卡流量:如何避免无法连接数据库的情况
1、减少从服务器的数量(从服务器会从主服务器复制日志)2、进行分级缓存(避免前端大量缓存失效)3、避免使用 select*
进行查询 4、分离业务网络和服务器网络
1.4 大表带来的问题(重要)
1.4.1 大表的特点
1、记录行数巨大,单表超千万 2、表数据文件巨大,超过 10
个 G
1.4.2 大表的危害
1、慢查询:很难在短时间内过滤出需要的数据
查询字区分度低 -> 要在大数据量的表中筛选出来其中一部分数据会产生大量的磁盘 io
-> 降低磁盘效率
2、对 DDL
影响:
建立索引需要很长时间:
MySQL-v<5.5
建立索引会锁表 MySQL-v>=5.5
建立索引会造成主从延迟(mysql
建立索引,先在组上执行,再在库上执行)
修改表结构需要长时间的锁表:会造成长时间的主从延迟(‘480 秒延迟 ’)
1.4.3 如何处理数据库上的大表
分库分表把一张大表分成多个小表
难点:
1、分表主键的选择 2、分表后跨分区数据的查询和统计
1.5 大事务带来的问题(重要)
1.5.1 什么是事务
事务是数据库系统区别于其他一切文件系统的重要特性之一
事务是一组具有原子性的 SQL 语句,或是一个独立的工作单元
事务要求符合:原子性、一致性、隔离性、持久性
1.5.2 事务的 ACID
属性
1、原子性(atomicity
):全部成功,全部回滚失败。银行存取款。
2、一致性(consistent):银行转账的总金额不变。
3、隔离性(isolation):
隔离性等级:
未提交读 (READ UNCOMMITED
) 脏读 , 两个事务之间互相可见;已提交读(READ COMMITED
) 符合隔离性的基本概念, 一个事务进行时,其它已提交的事物对于该事务是可见的,即可以获取其它事务提交的数据。可重复读(REPEATABLE READ
) InnoDB 的默认隔离等级
。事务进行时,其它所有事务对其不可见,即多次执行读,得到的结果是一样的!可串行化(SERIALIZABLE
)在读取的每一行数据上都加锁,会造成大量的锁超时和锁征用,严格数据一致性且没有并发是可使用。
查看系统的事务隔离级别:
show variables like'%iso%'
;
开启一个新事务:
begin
;
提交一个事务:
commit
;
修改事物的隔离级别:
setsession tx_isolation='read-committed'
;
4、持久性(DURABILITY
):从数据库的角度的持久性,磁盘损坏就不行了
redolog
机制保证事务更新的 一致性 和持久性
1.5.3 大事务
运行时间长,操作数据比较多的事务;
风险:锁定数据太多,回滚时间长,执行时间长。
1、锁定太多数据,造成大量阻塞和锁超时;
2、回滚时所需时间比较长,且数据仍然会处于锁定;
3、如果执行时间长,将造成主从延迟,因为只有当主服务器全部执行完写入日志时,从服务器才会开始进行同步,造成延迟。
解决思路:
1、避免一次处理太多数据,可以分批次处理;
2、移出不必要的 SELECT
操作,保证事务中只有必要的写操作。
什么影响了 MySQL 性能(非常重要)
2.1 影响性能的几个方面
1、服务器硬件。
2、服务器系统(系统参数优化)。
3、存储引擎。MyISAM
:不支持事务,表级锁。InnoDB
: 支持事务,支持行级锁,事务 ACID
4、数据库参数配置。
5、数据库结构设计和 SQL 语句。(重点优化)
2.2 MySQL 体系结构
分三层:客户端 -> 服务层 -> 存储引擎
1、MySQL
是 插件式的存储引擎 ,其中存储引擎分很多种。只要实现符合 mysql 存储引擎的接口,可以开发自己的存储引擎!
2、所有跨存储引擎的功能都是在服务层实现的。
3、MySQL 的 存储引擎是针对表的,不是针对库的。也就是说在一个数据库中可以使用不同的存储引擎。但是不建议这样做。
2.3 InnoDB 存储引擎
MySQL5.5
及之后版本 默认的存储引擎:InnoDB
。
2.3.1 InnoDB 使用表空间进行数据存储。
show variables like'innodb_file_per_table
如果 innodb_file_per_table 为 ON 将建立独立的表空间,文件为 tablename.ibd;
如果 innodb_file_per_table 为 OFF 将数据存储到系统的共享表空间,文件为 ibdataX(X 为从 1 开始的整数);
.frm
:是服务器层面产生的文件,类似服务器层的数据字典,记录表结构。
2.3.2 (MySQL5.5 默认)系统表空间与 (MySQL5.6
及以后默认)独立表空间
1、系统表空间无法简单的收缩文件大小,造成空间浪费,并会产生大量的磁盘碎片。
2、独立表空间可以通过 optimeze table
收缩系统文件,不需要重启服务器也不会影响对表的正常访问。
3、如果对多个表进行刷新时,实际上是顺序进行的,会产生 IO 瓶颈。
4、独立表空间可以同时向多个文件刷新数据。
强烈建立对 Innodb 使用独立表空间,优化什么的更方便,可控。
2.3.3 系统表空间的表转移到独立表空间中的方法
1、使用 mysqldump 导出所有数据库数据(存储过程、触发器、计划任务一起都要导出)可以在从服务器上操作。
2、停止 MYsql 服务器,修改参数(my.cnf 加入 innodb_file_per_table),并删除 Inoodb 相关文件(可以重建 Data 目录)。
3、重启 MYSQL,并重建 Innodb 系统表空间。
4、重新导入数据。
或者 Altertable
同样可以的转移,但是无法回收系统表空间中占用的空间。
2.4 InnoDB 存储引擎的特性
2.4.1 特性一:事务性存储引擎及两个特殊日志类型:Redo Log 和 Undo Log
1、Innodb
是一种 事务性存储引擎。
2、完全支持事务的 ACID
特性。
3、支持事务所需要的两个特殊日志类型:RedoLog
和 UndoLog
Redo Log:实现事务的持久性 (已提交的事务)。Undo Log: 未提交的事务,独立于表空间,需要随机访问,可以存储在高性能 io 设备上。
Undo
日志记录某数据被修改前的值,可以用来在事务失败时进行 rollback
;Redo
日志记录某数据块被修改后的值,可以用来恢复未写入 data file
的已成功事务更新的数据。
2.4.2 特性二:支持行级锁
1、InnoDB 支持行级锁。
2、行级锁可以最大程度地支持并发。
3、行级锁是由存储引擎层实现的。
2.5 什么是锁
2.5.1 锁
锁的主要作用是管理共享资源的并发访问
锁用于实现事务的隔离性
2.5.2 锁类型
2.5.3 锁的粒度
MySQL 的事务支持 不是绑定在 MySQL 服务器本身 , 而是与存储引擎相关
- 表级锁
- 行级锁
将 table_name 加表级锁命令:
locktable table_name write
; 写锁会阻塞其它用户对该表的‘读写’操作,直到
写锁被释放:unlock tables
;
1、锁的开销越大,粒度越小,并发度越高。
2、表级锁通常是在服务器层实现的。
3、行级锁是存储引擎层实现的。innodb 的锁机制,服务器层是不知道的
2.5.4 阻塞和死锁
1、阻塞是由于资源不足引起的排队等待现象。
2、死锁是由于两个对象在拥有一份资源的情况下申请另一份资源,而另一份资源恰好又是这两对象正持有的,导致两对象无法完成操作,且所持资源无法释放。
2.6 如何选择正确的存储引擎
参考条件:
1、事务 2、备份 (Innobd
免费在线备份) 3、崩溃恢复 4、存储引擎的特有特性
总结: nnodb 大法好。注意: 别使用混合存储引擎,比如回滚会出问题在线热备问题。
2.7 配置参数
2.7.1 内存配置相关参数
确定可以使用的内存上限。
内存的使用上限不能超过物理内存,否则容易造成内存溢出;(对于 32 位操作系统,MySQL 只能试用 3G 以下的内存
确定 MySQL 的 每个连接 单独
使用的内存。
sort_buffer_size
定义了每个线程排序缓存区的大小,MySQL 在有查询、需要做排序操作时才会为每个缓冲区分配内存(直接分配该参数的全部内存);
join_buffer_size
定义了每个线程所使用的连接缓冲区的大小,如果一个查询关联了多张表,MySQL 会为每张表分配一个连接缓冲,导致一个查询产生了多个连接缓冲;
read_buffer_size
定义了当对一张 MyISAM 进行全表扫描时所分配读缓冲池大小,MySQL 有查询需要时会为其分配内存,其必须是 4k 的倍数;
read_rnd_buffer_size
索引缓冲区大小,MySQL 有查询需要时会为其分配内存,只会分配需要的大小。
注意:以上四个参数是为一个线程分配的,如果有 100 个连接,那么需要×100。
MySQL 数据库实例:
MySQL 是 单进程多线程 (而 oracle 是多进程),也就是说 MySQL
实例在系统上表现就是一个服务进程,即进程;
MySQL 实例是线程和内存组成,实例才是真正用于操作数据库文件的;
一般情况下 一个实例操作一个或多个数据库;集群情况下 多个实例操作一个或多个数据库。
如何为缓存池分配内存:
Innodb_buffer_pool_size
定义了 Innodb 所使用缓存池的大小,对其性能十分重要,必须足够大,但是过大时,使得 Innodb 关闭时候需要更多时间把脏页从缓冲池中刷新到磁盘中;
总内存 -(每个线程所需要的内存 * 连接数)- 统保留内存
key_buffer_size
定义了 MyISAM 所使用的缓存池的大小,由于数据是依赖存储操作系统缓存的,所以要为操作系统预留更大的内存空间;
select sum(index_length) from information_schema.talbes where engine='myisam'
注意:即使开发使用的表全部是 Innodb 表,也要为 MyISAM 预留内存,因为 MySQL 系统使用的表仍然是 MyISAM 表。
max_connections
控制允许的最大连接数,一般 2000 更大。不要使用外键约束保证数据的完整性
2.8 性能优化顺序
- 库结构设计和 SQL 语句
- 数据库存储引擎的选择和参数配置
- 系统选择及优化
- 硬件升级