提高数据库的性能，和范式之间有什么关系

1、使你的数据库结构规范化，但是不要求一定达到第三范式，为了显示和打印目的可以有数据冗余2、评估你的系统中对性能影响的关键处，减少被频繁访问的核心表的数量，并在这些核心 表上重点优化索引，表结构（尽量紧凑）。典型的核心表是代码表。 3、对于统计类应用，如果可能应写成触发器和存储过程，这样就有可能把一个消耗大量时 间的统计运算分布到每INSERT，DELETE，或者UPDATE来处理，从而极大提高查询类 *** 作的速度。 查询选择群居索引最有效。其他索引也要针对业务进行选择。由于维护索引也要消耗系 统资源和时间，所以过多的索引对性能是损害甚至是毫无效果的。 5、如果可能，可以利用大数据库对SQL的一些特殊规定来进一步优化，比如查询暗示。 6、适当选择硬件，综合考虑CPU，内存，I/O系统的性能，以当前的CPU，内存配置来看， 很多数据库系统的瓶颈出在I/O系统上。所以如果有可能，最好使用RAID。 当然如果你有足够的财力，可以买更好的服务器，或者搞服务器集群就更利害啦。 7、可能的话，尽量使用存储过程，因为存储过程的执行计划可以重复使用，而且不需要 象普通由CLIENT提交的SQL那样进行处理和编译。 8、检查你的应用程序设计，如果有可能，尽量减少查询次数和在网络上往返的数据。为了 获取少量字段而写SELECT 对性能的损害也比较利害。 9、在应用程序中协调并发和一致性之间的矛盾。并不是所有业务都需要放在事务中。大量 业务是允许脏读的，在不关键事务中使用脏读，或者读提交，可以大大降低DEADLOCK和 进程之间彼此等待的机会，从而把由于互相锁定资源引起的等待降低到最小。 不要在事务执行中进行大量计算或者与用户交互的 *** 作，因为事务的执行在要求上是 不允许被打断的原子 *** 作（回滚是失败的），所以事务应该多而短小。长事务会锁住 很多资源比较长的时间，因此也比较容易导致其他进程对资源的等待和死锁的机会。

1、使你的数据库结构规范化，但是不要求一定达到第三范式，为了显示和打印目的可以有数据冗余2、评估你的系统中对性能影响的关键处，减少被频繁访问的核心表的数量，并在这些核心表上重点优化索引，表结构（尽量紧凑）。典型的核心表是代码表。3、对于统计类应用，如果可能应写成触发器和存储过程，这样就有可能把一个消耗大量时间的统计运算分布到每INSERT，DELETE，或者UPDATE来处理，从而极大提高查询类 *** 作的速度。查询选择群居索引最有效。其他索引也要针对业务进行选择。由于维护索引也要消耗系统资源和时间，所以过多的索引对性能是损害甚至是毫无效果的。5、如果可能，可以利用大数据库对SQL的一些特殊规定来进一步优化，比如查询暗示。6、适当选择硬件，综合考虑CPU，内存，I/O系统的性能，以当前的CPU，内存配置来看，很多数据库系统的瓶颈出在I/O系统上。所以如果有可能，最好使用RAID。当然如果你有足够的财力，可以买更好的服务器，或者搞服务器集群就更利害啦。7、可能的话，尽量使用存储过程，因为存储过程的执行计划可以重复使用，而且不需要象普通由CLIENT提交的SQL那样进行处理和编译。8、检查你的应用程序设计，如果有可能，尽量减少查询次数和在网络上往返的数据。为了获取少量字段而写SELECT 对性能的损害也比较利害。9、在应用程序中协调并发和一致性之间的矛盾。并不是所有业务都需要放在事务中。大量业务是允许脏读的，在不关键事务中使用脏读，或者读提交，可以大大降低DEADLOCK和进程之间彼此等待的机会，从而把由于互相锁定资源引起的等待降低到最小。不要在事务执行中进行大量计算或者与用户交互的 *** 作，因为事务的执行在要求上是不允许被打断的原子 *** 作（回滚是失败的），所以事务应该多而短小。长事务会锁住很多资源比较长的时间，因此也比较容易导致其他进程对资源的等待和死锁的机会。10、评估你开发系统的关键业务，在很多数据库系统对性能的要求是彼此矛盾的，比如OLTP应用和DSS是不同的。DSS倾向于使用各种索引加快检索速度，而大量的索引对OLTP则是负担。11、不要在应用程序中写怪异的SQL 查询，比如 WHERE money!40000，这样的语句，这种SQL查询，数据库的SQL优化器是无法进行优化的。12、定期维护和管理你的数据库系统，压缩掉那些垃圾空间，很多数据库系统执行类似删除，事务等 *** 作的时候，并不回收无用的物理空间。所以，制定一份合理的数据库维护计划，不要等日志文件或者LOG文件越长越大的时候才去整理数据库。还有很多很多要注意的东西，。。。。。。

    具体问题具体分析，举例来说明为什么磁盘IO成瓶颈数据库的性能急速下降了。

   为什么当磁盘IO成瓶颈之后, 数据库的性能不是达到饱和的平衡状态，而是急剧下降。为什么数据库的性能有非常明显的分界点，原因是什么？

    相信大部分做数据库运维的朋友，都遇到这种情况。 数据库在前一天性能表现的相当稳定，数据库的响应时间也很正常，但就在今天，在业务人员反馈业务流量没有任何上升的情况下，数据库的变得不稳定了，有时候一个最简单的insert *** 作， 需要几十秒，但99%的insert却又可以在几毫秒完成，这又是为什么了？

dba此时心中有无限的疑惑，到底是什么原因呢 磁盘IO性能变差了？还是业务运维人员反馈的流量压根就不对？ 还是数据库内部出问题？昨天不是还好好的吗？

 当数据库出现响应时间不稳定的时候，我们在 *** 作系统上会看到磁盘的利用率会比较高，如果观察仔细一点，还可以看到，存在一些读的IO 数据库服务器如果存在大量的写IO,性能一般都是正常跟稳定的，但只要存在少量的读IO,则性能开始出现抖动，存在大量的读IO时（排除配备非常高速磁盘的机器），对于在线交易的数据库系统来说，大概性能就雪崩了。为什么 *** 作系统上看到的磁盘读IO跟写IO所带来的性能差距这么大呢？

如果亲之前没有注意到上述的现象，亲对上述的结论也是怀疑。但请看下面的分解。

在写这个文章之前，作者阅读了大量跟的IO相关的代码，如异步IO线程的相关的，innodb_buffer池相关的，以及跟读数据块最相关的核心函数buf_page_get_gen函数以及其调用的相关子函数。为了将文章写得通俗点，看起来不那么累，因此不再一行一行的将代码解析写出来。

咱们先来提问题。 buf_page_get_gen函数的作用是从Buffer bool里面读数据页，可能存在以下几种情况。

提问 数据页不在buffer bool 里面该怎么办？

  回答：去读文件，将文件中的数据页加载到buffer pool里面。下面是函数buffer_read_page的函数，作用是将物理数据页加载到buffer pool, 中显示

buffer_read_page函数栈的顶层是pread64(),调用了 *** 作系统的读函数。

buf_read_page的代码

 如果去读文件，则需要等待物理读IO的完成，如果此时IO没有及时响应，则存在堵塞。这是一个同步读的 *** 作，如果不完成该线程无法继续后续的步骤。因为需要的数据页不再buffer 中，无法直接使用该数据页，必须等待 *** 作系统完成IO

再接着上面的回答提问：

当第二会话线程执行sql的时候，也需要去访问相同的数据页，它是等待上面的线程将这个数据页读入到缓存中，还是自己再发起一个读磁盘的然后加载到buffer的请求呢？   代码告诉我们，是前者，等待第一个请求该数据页的线程读入buffer pool。

试想一下，如果第一个请求该数据页的线程因为磁盘IO瓶颈，迟迟没有将物理数据页读入buffer pool, 这个时间区间拖得越长，则造成等待该数据块的用户线程就越多。对高并发的系统来说，将造成大量的等待。 等待数据页读入的函数是buf_wait_for_read，下面是该函数相关的栈。

通过解析buf_wait_for_read函数的下层函数，我们知道其实通过首先自旋加锁pin的方式，超过设定的自旋次数之后，进入等待，等待IO完成被唤醒。这样节省不停自旋pin时消耗的cpu,但需要付出被唤起时的开销。

再继续扩展问题： 如果会话线程A 经过物理IO将数据页1001读入buffer之后，他需要修改这个页，而在会话线程A之后的其他的同样需要访问数据页1001的会话线程，即使在数据页1001被入读buffer pool之后，将仍然处于等待中。因为在数据页上读取或者更新的时候，同样需要上锁，这样才能保证数据页并发读取/更新的一致性。

由此可见，当一个高并发的系统，出现了热点数据页需要从磁盘上加载到buffer pool中时，造成的延迟，是难以想象的。因此排在等待热点页队列最后的会话线程最后才得到需要的页，响应时间也就越长，这就是造成了一个简单的sql需要执行几十秒的原因。

再回头来看上面的问题，mysql数据库出现性能下降时，可以看到 *** 作系统有读IO。 原因是，在数据库对数据页的更改，是在内存中的，然后通过检查点线程进行异步写盘，这个异步的写 *** 作是不堵塞执行sql的会话线程的。所以，即使看到 *** 作系统上有大量的写IO，数据库的性能也是很平稳的。但当用户线程需要查找的数据页不在buffer pool中时，则会从磁盘上读取，在一个热点数据页不是非常多的情况下，我们设置足够大的innodb_buffer_pool的size, 基本可以缓存所有的数据页，因此一般都不会出现缺页的情况，也就是在 *** 作系统上基本看不到读的IO。  当出现读的IO时，原因时在执行buf_read_page_low函数，从磁盘上读取数据页到buffer pool, 则数据库的性能则开始下降，当出现大量的读IO，数据库的性能会非常差。

在需要支持移动/平板电脑应用及普通桌面浏览器访问的时代，网站的普及率和有效性很大程度上取决于其可用性和性能。一个访问缓慢的网站会使得访问者或潜在的客户流失，并导致商业的失败。IT培训认为一个访问速度相当快的网站将会决定访客是否会使用网站提供的产品或服务。

拥有大规模数据库的网站始终需要适当的关注、配置、优化、调整和维护，以确保网站的快速加载。这篇文章将讨论如何优化有海量数据的MySQL数据库。

选择InnoDB作为存储引擎

大型产品的数据库对于可靠性和并发性的要求较高，InnoDB作为默认的MySQL存储引擎，相对于MyISAM来说是个更佳的选择。

优化数据库结构

组织数据库的schema、表和字段以降低I/O的开销，将相关项保存在一起，并提前规划，以便随着数据量的增长，性能可以保持较高的水平。

设计数据表应尽量使其占用的空间最小化，表的主键应尽可能短。

对于InnoDB表，主键所在的列在每个辅助索引条目中都是可复制的，因此如果有很多辅助索引，那么一个短的主键可以节省大量空间。

仅创建你需要改进查询性能的索引。索引有助于检索，但是会增加插入和更新 *** 作的执行时间。

InnoDB的ChangeBuffering特性

InnoDB提供了changebuffering的配置，可减少维护辅助索引所需的磁盘I/O。大规模的数据库可能会遇到大量的表 *** 作和大量的I/O，以保证辅助索引保持最新。当相关页面不在缓冲池里面时，InnoDB的changebuffer将会更改缓存到辅助索引条目，从而避免因不能立即从磁盘读取页面而导致耗时的I/O *** 作。当页面被加载到缓冲池时，缓冲的更改将被合并，更新的页面之后会刷新到磁盘。这样做可提高性能，适用于MySQL55及更高版本。

以上就是关于提高数据库的性能，和范式之间有什么关系全部的内容，包括:提高数据库的性能，和范式之间有什么关系、怎样提高数据库的性能、如何处理查找，处理数据库的性能瓶颈等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！