高性能MySQL(第二版)第一章 基础篇——读书笔记

一.MySQL服务器架构的逻辑视图

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)

五.为自己的应用选择合适的数据库引擎

     在设计基于MySQL的应用时，要决定选择何种存储引擎来存储数据。如果不在设计阶段就考虑这个问题，在后续工作中可能就会面临复杂的问题。用户可能会发现默认配置的引擎并不能满足自己的某种需要，比如事务。或者，应用产生的混合读写查询需要更细粒度的加锁机制，而不是MyISAM提供的表锁。

     引擎的选择可以基于每一张表，因此，需要清醒的考虑如何使用每一张表，以及如何存储数据。这种考虑也有助用户从整体上正确的理解应用，并且预测应用的增长需求，理解和掌握相关信息为自己的应用选择合适的引擎。