高性能MySQL(第二版)第一章 基础篇——读书笔记
2013-01-24 15:41
381 查看
一.MySQL服务器架构的逻辑视图
![](http://img.my.csdn.net/uploads/201301/24/1359013568_4575.png)
![](file:///c:\docume~1\16973\locals~1\temp\enhtmlclip\image.png)
![](file:///c:\docume~1\16973\locals~1\temp\enhtmlclip\image.png)
1.连接管理与安全性
2.优化查询
1>解析查询
2>创建内部数据结构(解析树)
3>优化
重写查询
决定查询的读表顺序
选择需使用的索引
存储引擎对服务器的查询优化过程有影响。
服务器会“询问”查询缓存。
用户可以通过特殊的关键字给优化器传递各种提示,影响它的优化过程。还可以请求服务器给出优化过程的各种说明.使用户可以知晓服务器是如何进行优化决策的,为用户提供一个参考基准。方便用户重写查询,架构和修改相关配置,便于应用尽可能高效的运行。
二.并发控制
1. 读锁(Read Lock)/写锁(Write Lock)
某一资源上的读锁是共享的,或者说是互补阻塞的。在同一时间,多个用户可以同时读取同一资源,而互不干扰。
写锁是排他的,一个写锁会阻塞其他的读锁或者写锁。在给定时间里,只有一个用户能写入资源。
2.锁粒度(Lock Granularity)
一种提高共享资源并发性的方法:
只锁定部分须修改的数据,而不是所有的资源。任何时间,在给定的资源上,被加锁的数据量越小,就可以允许更多的并发修改,只要相互之间互不冲突即可。
另外一方面,加锁也会消耗系统资源。每一种锁操作,如获得锁,检查锁是否已解除,以及释放锁等。都会增加系统的开销。如果系统花大量时间来管理锁,而不是读/写数据,那么系统整体性能可能会受此影响。
所谓的锁策略,就是在锁开销和数据安全之间寻求一种平衡,这种平衡也能影响系统性能。
表锁
MySQL中,开销最小的锁策略是表锁。
行级锁
行级锁可以带来最大的并发处理(同时也带来最大的开销)。
三.事务
关于事务,银行应用是一个经典的案例,可以解释事务应用的必要性。假设一银行数据库有两张表,checking表和saving表。现在要从Jane的支票账户(checking Account)转账200美元到她的存款账户(savings Account),那么需要完成至少三步操作:
1.检查支票存款账户的余额是否大于200$
2.从支票存款账户余额中减去200$
3.在存款账户余额中增加200$
所有的操作被打包到一个事务里,如果某一步失败,就回滚(rollback)所有已完成的步骤。
可以用start transaction 语句开始一个事务,用COMMIT语句提交整个事务,永久的修改数据,或者用ROLLBACK语句回滚整个事务,取消已做的修改。事务SQL案例如下:
1.start transaction;
2.select balance from checking where custom_id = 1005373;
3.update checking set balance = balance -200.00 where customer_id = 1005373;
4.update savings set balance = balance + 200.00 where customer_id = 1005373;
5.commit;
试想一下,如果数据库服务器在执行第4句语句时,数据库突然崩溃,会发生什么事儿?没有人知道,但是用户可能会损失200元美元。再加入,在执行第3和第4句之间时,另一个进程同时运行,它的母的是要先删除支票账户的全部余额,那么结果可能是,银行根本不知道有这个逻辑事先发生,白白给用户增加了200元存款。
除非系统通过ACID测试,否则空谈事务概念是不够的,ACID代表了原子性,一致性,隔离性和持久性。这些概念与事务的处理标准密切关联,一个有效的事务处理系统必须满足相关标准。
a.原子性 b.一致性 c.隔离性 d.持久性
1.隔离级
读取未提交内容
读取提交内容
可重读
可串行化
读取未提交内容和可重读的区别:
如果你从控制的角度来看,两者的区别就比较大:对于前者,只需要锁住满足条件的记录;对于后者,要锁住满足条件及其附近的记录。
2.死锁
死锁是指两个或者多个事务在同一资源上互相占用,并请求加锁时,而导致的恶性循环现象。当多个事务以不同顺序试图对同一资源加锁时,就会产生死锁。任何时间,多个事务同时加锁一个资源,一定产生死锁。例如,设想下列两个事务同时处理StockPrice表:
事务1
start transaction;
update StockPrice set close = 45.50
where stock_id = 4 and date =
'2002-05-01';
update StockPrice set close = 19.80
where stock_id = 3 and date =
'2002-05-02';
commit;
事务2
start transaction;
update StockPriceset close = 19.80where stock_id = 3and date ='2002-05-02';
update StockPriceset close = 45.50where stock_id = 4and date ='2002-05-01';
commit;
如果很不幸凑巧,每个事务在处理过程中,都执行了第一个查询,又更新了数据行,也加锁了该数据行。接着,每个事务都去视图更新第二个数据行,却发现该行已被(对方)加锁,然后两个事务都开始互相等待对方完成,陷入无限等待中,除非有外部因素介入,才能解除死锁。
为了解决这个问题,数据库系统事先了各种死锁检测和死锁超时机制。对于更复杂的系统。例如InnoDB存储引擎,可以预测循环相关性,并立即返回错误。这种解决方式实际很有效,否则死锁将导致很慢的查询,其他的解决方式,是让查询到达一个锁等待超时时间,然后再放弃争用,但这种方式不够好。目前InnoDB处理死锁的方法是,回滚拥有最少排他行级的事务(一种对最易回滚事务的大致估算)
三.事务日志
事务日志可使事务处理过程更加高效,和每次数据以改变就更新磁盘中表数据的方式不同,存储引擎可以先更新数据的内存中得拷贝。这非常快,然后,存储引擎将数据改变记录写入事务日志,它位于磁盘上,因此具有持久性。这相对较快,因为追加日志事件导致的写操作,只涉及了磁盘很小区域上得顺序I/O(Sequential I/O),而替代了写磁盘中表所需要的大量随机I/O(Random I/O).
最后,相关进程会在某个事件把表数据更新到磁盘上。因此大多存储引擎都选用了这种技术,也是通常所说的预写式日志,利用两次磁盘写入操作把数据改变磁盘。
四,多版本并发控制(MVCC , Multiversion Concurrentcy Control)
![](http://img.my.csdn.net/uploads/201301/24/1359013755_5642.jpg)
五.为自己的应用选择合适的数据库引擎
在设计基于MySQL的应用时,要决定选择何种存储引擎来存储数据。如果不在设计阶段就考虑这个问题,在后续工作中可能就会面临复杂的问题。用户可能会发现默认配置的引擎并不能满足自己的某种需要,比如事务。或者,应用产生的混合读写查询需要更细粒度的加锁机制,而不是MyISAM提供的表锁。
引擎的选择可以基于每一张表,因此,需要清醒的考虑如何使用每一张表,以及如何存储数据。这种考虑也有助用户从整体上正确的理解应用,并且预测应用的增长需求,理解和掌握相关信息为自己的应用选择合适的引擎。
![](http://img.my.csdn.net/uploads/201301/24/1359013568_4575.png)
![](file:///c:\docume~1\16973\locals~1\temp\enhtmlclip\image.png)
![](file:///c:\docume~1\16973\locals~1\temp\enhtmlclip\image.png)
1.连接管理与安全性
2.优化查询
1>解析查询
2>创建内部数据结构(解析树)
3>优化
重写查询
决定查询的读表顺序
选择需使用的索引
存储引擎对服务器的查询优化过程有影响。
服务器会“询问”查询缓存。
用户可以通过特殊的关键字给优化器传递各种提示,影响它的优化过程。还可以请求服务器给出优化过程的各种说明.使用户可以知晓服务器是如何进行优化决策的,为用户提供一个参考基准。方便用户重写查询,架构和修改相关配置,便于应用尽可能高效的运行。
二.并发控制
1. 读锁(Read Lock)/写锁(Write Lock)
某一资源上的读锁是共享的,或者说是互补阻塞的。在同一时间,多个用户可以同时读取同一资源,而互不干扰。
写锁是排他的,一个写锁会阻塞其他的读锁或者写锁。在给定时间里,只有一个用户能写入资源。
2.锁粒度(Lock Granularity)
一种提高共享资源并发性的方法:
只锁定部分须修改的数据,而不是所有的资源。任何时间,在给定的资源上,被加锁的数据量越小,就可以允许更多的并发修改,只要相互之间互不冲突即可。
另外一方面,加锁也会消耗系统资源。每一种锁操作,如获得锁,检查锁是否已解除,以及释放锁等。都会增加系统的开销。如果系统花大量时间来管理锁,而不是读/写数据,那么系统整体性能可能会受此影响。
所谓的锁策略,就是在锁开销和数据安全之间寻求一种平衡,这种平衡也能影响系统性能。
表锁
MySQL中,开销最小的锁策略是表锁。
行级锁
行级锁可以带来最大的并发处理(同时也带来最大的开销)。
三.事务
关于事务,银行应用是一个经典的案例,可以解释事务应用的必要性。假设一银行数据库有两张表,checking表和saving表。现在要从Jane的支票账户(checking Account)转账200美元到她的存款账户(savings Account),那么需要完成至少三步操作:
1.检查支票存款账户的余额是否大于200$
2.从支票存款账户余额中减去200$
3.在存款账户余额中增加200$
所有的操作被打包到一个事务里,如果某一步失败,就回滚(rollback)所有已完成的步骤。
可以用start transaction 语句开始一个事务,用COMMIT语句提交整个事务,永久的修改数据,或者用ROLLBACK语句回滚整个事务,取消已做的修改。事务SQL案例如下:
1.start transaction;
2.select balance from checking where custom_id = 1005373;
3.update checking set balance = balance -200.00 where customer_id = 1005373;
4.update savings set balance = balance + 200.00 where customer_id = 1005373;
5.commit;
试想一下,如果数据库服务器在执行第4句语句时,数据库突然崩溃,会发生什么事儿?没有人知道,但是用户可能会损失200元美元。再加入,在执行第3和第4句之间时,另一个进程同时运行,它的母的是要先删除支票账户的全部余额,那么结果可能是,银行根本不知道有这个逻辑事先发生,白白给用户增加了200元存款。
除非系统通过ACID测试,否则空谈事务概念是不够的,ACID代表了原子性,一致性,隔离性和持久性。这些概念与事务的处理标准密切关联,一个有效的事务处理系统必须满足相关标准。
a.原子性 b.一致性 c.隔离性 d.持久性
1.隔离级
读取未提交内容
读取提交内容
可重读
可串行化
读取未提交内容和可重读的区别:
如果你从控制的角度来看,两者的区别就比较大:对于前者,只需要锁住满足条件的记录;对于后者,要锁住满足条件及其附近的记录。
2.死锁
死锁是指两个或者多个事务在同一资源上互相占用,并请求加锁时,而导致的恶性循环现象。当多个事务以不同顺序试图对同一资源加锁时,就会产生死锁。任何时间,多个事务同时加锁一个资源,一定产生死锁。例如,设想下列两个事务同时处理StockPrice表:
事务1
start transaction;
update StockPrice set close = 45.50
where stock_id = 4 and date =
'2002-05-01';
update StockPrice set close = 19.80
where stock_id = 3 and date =
'2002-05-02';
commit;
事务2
start transaction;
update StockPriceset close = 19.80where stock_id = 3and date ='2002-05-02';
update StockPriceset close = 45.50where stock_id = 4and date ='2002-05-01';
commit;
如果很不幸凑巧,每个事务在处理过程中,都执行了第一个查询,又更新了数据行,也加锁了该数据行。接着,每个事务都去视图更新第二个数据行,却发现该行已被(对方)加锁,然后两个事务都开始互相等待对方完成,陷入无限等待中,除非有外部因素介入,才能解除死锁。
为了解决这个问题,数据库系统事先了各种死锁检测和死锁超时机制。对于更复杂的系统。例如InnoDB存储引擎,可以预测循环相关性,并立即返回错误。这种解决方式实际很有效,否则死锁将导致很慢的查询,其他的解决方式,是让查询到达一个锁等待超时时间,然后再放弃争用,但这种方式不够好。目前InnoDB处理死锁的方法是,回滚拥有最少排他行级的事务(一种对最易回滚事务的大致估算)
三.事务日志
事务日志可使事务处理过程更加高效,和每次数据以改变就更新磁盘中表数据的方式不同,存储引擎可以先更新数据的内存中得拷贝。这非常快,然后,存储引擎将数据改变记录写入事务日志,它位于磁盘上,因此具有持久性。这相对较快,因为追加日志事件导致的写操作,只涉及了磁盘很小区域上得顺序I/O(Sequential I/O),而替代了写磁盘中表所需要的大量随机I/O(Random I/O).
最后,相关进程会在某个事件把表数据更新到磁盘上。因此大多存储引擎都选用了这种技术,也是通常所说的预写式日志,利用两次磁盘写入操作把数据改变磁盘。
四,多版本并发控制(MVCC , Multiversion Concurrentcy Control)
![](http://img.my.csdn.net/uploads/201301/24/1359013755_5642.jpg)
五.为自己的应用选择合适的数据库引擎
在设计基于MySQL的应用时,要决定选择何种存储引擎来存储数据。如果不在设计阶段就考虑这个问题,在后续工作中可能就会面临复杂的问题。用户可能会发现默认配置的引擎并不能满足自己的某种需要,比如事务。或者,应用产生的混合读写查询需要更细粒度的加锁机制,而不是MyISAM提供的表锁。
引擎的选择可以基于每一张表,因此,需要清醒的考虑如何使用每一张表,以及如何存储数据。这种考虑也有助用户从整体上正确的理解应用,并且预测应用的增长需求,理解和掌握相关信息为自己的应用选择合适的引擎。
![](http://img.my.csdn.net/uploads/201301/25/1359098848_9735.jpg)
相关文章推荐
- 鸟哥Linux私房菜_基础篇(第二版)_第一章学习笔记
- 第六章 优化服务器设置--高性能MySQL 施瓦茨--读书笔记
- 《MySQL DBA修炼之道》 读书笔记(第一章 理解MySQL)
- 《鸟哥的Linux学习:基础篇》第一章 Linux是什么 读书笔记
- java面向对象编程(第二版)读书笔记-------第一章
- 【读书笔记】【MySQL高性能】Schema与数据类型优化
- 编程珠玑(第二版)读书笔记第一章
- 《人工智能(智能系统指南,第二版)》读书笔记——2、第一章
- 深入理解计算机操作系统(第二版) 读书笔记(第一章 计算机系统漫游)
- windows网络编程第二版 第一章 winsock简介 读书笔记
- mysql高性能扩展_____第一章
- 高性能MySQL第一章笔记
- MySQL从菜鸟到专家[基础篇]---第一章(Mysql概述以及安装详解)
- MySQL高性能——第一章
- 《高性能 MySQL》读书笔记
- 高性能MYSQL--第一章
- 【高性能Mysql】读书笔记
- 高性能MySQL:第一章 MySQL架构与历史
- 《高性能MySQL》读书笔记--查询缓存
- 高性能Mysql学习笔记之第一章