数据库优化-1

         没有稳定的数据库及服务器环境一切的一切都是一场空

       一主多从的数据库架构  没有任何的主从复制的组件  这种数据库的架构的不足就是 主服务器出现问题后不能有效的进行故障切换必须是手动在从服务器中选择一台数据最新的从服务器来提升成主服务器  其他的从服务器进行新主的同步（这个过程是非常耗时间的）

并发量： 同一时间处理的请求数量

fashion IO  这种设备比一般的磁盘吞吐量大的很多

影响数据库性能的因素有哪些？？

                1、sql的查询速度 2、服务器的硬件（CPU   内存 等）3、网卡的流量 4、磁盘的io  5、大表   6、大事务

超高的QPS和TPS会造成哪些风险呢？？？

    效率低下的SQL （在当前的MySQL中不支持多CPU的并发运算，也就是说，一个SQL只能用到一个cpu）；

什么是QPS呢？？？？

    每秒的处理的查询数量

大量的并发和超高的CPU使用率会有哪些风险呢？？？

       大量的并发会造成数据库的连接数被占满

       超高的cpu使用率会因为CPU的资源耗尽而出现的宕机

什么是并发量呢？？？

      是指同一时刻所需要数据库服务器请求的数量

什么是连接量呢？？？

         连接量要比并发量大的多，每一个前段服务器（Nginx Apache）等服务器都会和数据库进行多个连接，而在众多的连接中，只有少数几个是进行数据库请求处理的，其他 的大部分的是处于一种 selp，但对数据库来说所允许建立的连接数它是有限的， 在MySQL中这个限制是由  max_connections 这个参数来控制的 默认的连接数是100。

磁盘IO会给我们带来哪些性能的危险？？？

         数据库的主要瓶颈就是磁盘IO 

        风险  ：   1、磁盘IO性能的突然下降（通过使用更快的磁盘设备）2、取消其他大量消耗磁盘性能的计划任务（调整计划，做好磁盘维护）；

网卡流量对数据库造成的影响：

       风险：网卡IO会被占满

如何避免无法连接数据库的情况：

     减少从服务器的数量

     进行分级缓存

     避免使用 "select   *  "  进行查询

     分离业务网络和服务器网络

什么样的表可以称之为大表呢？

      记录行数巨大，单表超过千万行

      表数据文件巨大，表数据文件超过10G

大表给我们带来的问题：

       大表对查询的影响    大表也就往往意味着慢查询的产生    

       那么什么是慢查询呢？

               慢查询就是很难在一定的时间内过滤出所需要的数据

大表对DDL的影响

        建立索引需要更多的时间  这样的风险是：MySQL5.5之前建立索引会进行锁表     而在MySQL5.5之后虽然不会锁表但会引起主从延迟

        修改表结构需要长时间的锁表    这样的风险是：1、会造成长时间的主从延迟 2、 影响正常的数据操作

如何处理数据库中的大表

          分库分表   难点    1、分表主键的选择    2、分表后跨分区数据查询和统计

          大表的历史数据归档（减少对前后端业务的影响）   难点： 1、归档的时间点的选择     2、如何进行归档操作

大事务带来的问题

   什么是事务？？？？

          1、事务就是数据库系统区别于其他一切文件系统的重要特性之一；

          2、事务是一组具有原子性的SQL语句，或是一个独立的工作单元；

  事务的4大特性

      1、原子性     事务是数据库的逻辑工作单位，事务中包括的诸操作要么全做，要么全不做

      2、一致性     事务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。一致性与原子性是密切相关的。

      3、隔离性     一个事务的执行不能被其他事务干扰。（SQL标准中定义的4个隔离级别1、未提交读【PEAD UNCOMMITED】2、已提交读【PEAD COMMITED】3、可重复读【REPEATABLE READ 】4、可串行化【SERIALIZABLE】）

      4、持久性    一个事务一旦提交，它对数据库中数据的改变就应该是永久性的。

什么是大事务

   定义：运行时间比较长，操作的数据库比较多的事务

   风险；1、锁定太多的数据，造成大量的阻塞和锁超时 2、回滚时所需的时间长 3、执行时间长，容易造成主从延迟

如何处理大事务

     1、避免一次处理太多的数据

      2、移除不必要在事务中的SELECT操作

未完          待续