如何在数据库设计过程中优化大量数据？

数据库优化说起来很简单。

就像抽水的木桶一样，瓶颈降低了。 首先，我们需要分析数据库操作。

看看哪些有更多的等待时间，有哪些瓶颈。 喜欢 CPU？ io？很多硬解析？ 缓存命中率低？ 然后分别处理它们。 从数据库整体的角度来看，一般需要根据主机配置和实际使用情况，对SGA的容量进行一些配置调整。 增加数据文件，分配表空间，正确分区，减少 I/O 热点。

但是，大多数时候数据库优化会体现在SQL上，而大部分有问题的数据库都有异常的执行计划，或者表设计不合理等，导致一些SQL语句的执行效率极低，影响了数据库的性能。

存储引擎的选择; 表结构，包括索引、字段类型、表数据; SQL不能写得太糟糕，至少通过解释测试查询来利用索引; 硬件优化，包括CPU、内存、磁盘IO等。

1.在硬件方面，服务器应该不会太差，磁盘的读写性能会影响IO，可以认为使用好的硬盘，比如SSD

2.根据服务器设置数据库的参数，比如内存什么的 3、在设计表时，应选择字段类型并建立正确的索引 4.SQL优化，尽量使用索引，不要出现全表扫描等，网上有很多这样的信息，这些我就说大概这些了。

MRR 是针对特定查询的 MySQL 优化。 假设某个查询有一个二级索引可用，读取二级索引后，需要返回表中查找当前二级索引上没有的列值，因为二级索引上引用的主键值不一定是有序的，所以可能会造成大量随机 ios。

如果要关闭 MRR 优化，则需要将优化器切换 MRR 设置为 OFF。

默认情况下，只有当优化器认为 MRR 可以带来优化时才会采取 MRR，如果你想尽可能地采取 MRR，你需要将 MRR Cost Based 设置为 OFF，但最好不要这样做，因为这确实是一个陷阱，MRR 不一定一直都很好， 全表扫描有时会更快，如果您在这种情况下进行 MRR，它将完成。

MRR 对主键进行排序，以便磁盘上的后续操作是顺序读取，而不是随机读取。 从资源使用的角度来看，就是让CPU和内存做更多的工作来交换磁盘的顺序读取。 但是，排序需要内存，并且此内存的大小由 read rnd buffer size 参数控制。

在数据库优化方面，可以从以下几个方面入手：

若要优化查询以避免全表扫描，应首先考虑为 where 和 order by 中涉及的列编制索引。

应尽可能避免对 where 子句中的字段进行空值判断。

在 where 子句中应尽可能避免使用 ！= 或 <>运算符。

查询时，选择后不要使用 *，手动添加字段名称。

关于软件优化的简单介绍：

SQL：索引调整：前提条件，数据量大，频繁只读查询SQL语言优化等查询，连接表过多会影响数据库性能设计合理，这意味着数据库是按照数据库规范化数据库Oracle内部参数调整设计的：

调整文件的环境参数。

DB 块大小：数据库中每个数据块的大小，默认为 2048 字节（2K），应增加到 4K 或 8K，大型数据库常用 16K 和 32K，SGA 也应增加。

共享池大小：共享池大小是否合适，可以通过对数据库的监控或一些SQL语句来获取。

日志缓冲区：为了减少 LGWR 和 DBWR 之间的冲突，大型数据库的日志缓冲区通常手动更大，通常为 2 到 3 M。

所有环境参数都可以通过系统的监控工具进行分析。

另外：适当地修改数据库块大小。

应用优化。

批量应用优化。

优化单个SQL语句。

摘要：良好的数据库设计。

良好的建筑设计。

良好的平台（硬件平台、网络平台）。

合理、充分的合理环境参数指标（操作系统环境参数、预言机环境参数）。

良好的DBA可以持续优化（管理）。

Oracle：海量数据库。

SQL Server：适用于中小型企业的数据库。

优化的概念太宽泛了，无法用一两千字来完成。

Oracle 和 SQL Server 的区别其实并不大，都是商业数据库，而且应用广泛。

无非是 SQL Server 在过去两年中得到了非常强大的更新，并且可编程性有所提高。

其实没有太大的区别，用不同的需求，用不同的数据库。

索引调整：前提条件、数据量大、只读查询频繁 语言优化。