当查询数据库时，由于数据不断增加，查询变得越来越慢，请问有什么方法可以优化，使查询变快

在数据库表中加字段，将数据分类，比如插入时间、数据类别、包含什么特殊文字的字符串，都可以分类。然后可以将分类后的数据，放入其他不同的表中，这样就可以将大数据变成小数据进行查询了。之后加索引，加分区可能会更快。

body{

line-height:200%;

}

如何优化MySQL数据库

当MySQL数据库邂逅优化，它有好几个意思，今天我们所指的是性能优化。

我们究竟该如何对MySQL数据库进行优化呢？下面我就从MySQL对硬件的选择、Mysql的安装、myf的优化、MySQL如何进行架构设计及数据切分等方面来说明这个问题。

1服务器物理硬件的优化

1)磁盘(I/O)，MySQL每一秒钟都在进行大量、复杂的查询 *** 作，对磁盘的读写量可想而知，所以推荐使用RAID10磁盘阵列，如果资金允许，可以选择固态硬盘做RAID10；

2)cpu对Mysql的影响也是不容忽视的，建议选择运算能力强悍的CPU。

2MySQL应该采用编译安装的方式

MySQL数据库的线上环境安装，我建议采取编译安装，这样性能会较大的提升。

3MySQL配置文件的优化

1)skip

-name

-resolve，禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间；

2)back_log

=

384，back_log指出在MySQL暂时停止响应新请求之前，短时间内的多少个请求可以被存在堆栈中，对于Linux系统而言，推荐设置小于512的整数。

3)如果key_reads太大，则应该把myf中key_buffer_size变大，保持key_reads/key_read_requests至少在1/100以上，越小越好。

4MySQL上线后根据status状态进行适当优化

1)打开慢查询日志可能会对系统性能有一点点影响，如果你的MySQL是主-从结构，可以考虑打开其中一台从服务器的慢查询日志，这样既可以监控慢查询，对系统性能影响也会很小。

2)MySQL服务器过去的最大连接数是245，没有达到服务器连接数的上限256，应该不会出现1040错误。比较理想的设置是：Max_used_connections/max_connections

100%

=85%

5MySQL数据库的可扩展架构方案

1)MySQL

cluster，其特点为可用性非常高，性能非常好，但它的维护非常复杂，存在部分Bug;

2)DRBD磁盘网络镜像方案，其特点为软件功能强大，数据可在底层块设备级别跨物理主机镜像，且可根据性能和可靠性要求配置不同级别的同步。

官方建议： Min（32GB，机器内存大小/2）。

磁盘需求最优比例=1:50 256g=12800G=13T

8G内存对应850=400G磁盘

总体内存大小没有具体要求，但肯定是内容越大，检索性能越好。

除了JVM之外的预留内存要充足，否则也会经常OOM。

集群节点数：<=3，建议：所有节点的master：true， data：true。既是主节点也是路由节点。

集群节点数：>3, 根据业务场景需要，建议：逐步独立出Master节点和协调/路由节点。

ES 集群中的数据节点负责对数据进行增、删、改、查和聚合等 *** 作，所以对 CPU、内存和 I/O 的消耗很大。

在搭建 ES 集群时，我们应该对 ES 集群中的节点进行角色划分和隔离。

候选主节点：nodemaster= true node data= false

数据节点：nodemaster= false node data= true

网络异常可能会导致集群中节点划分出多个区域，区域发现没有 Master 节点的时候，会选举出了自己区域内 Maste 节点 r，导致一个集群被分裂为多个集群，使集群之间的数据无法同步，我们称这种现象为脑裂。

为了防止脑裂，我们需要在 Master 节点的配置文件中添加如下参数：

discoveryzenminimum_master_nodes=（master_eligible_nodes /2）+1 //默认值为 1

其中 master_eligible_nodes 为 Master 集群中的节点数。这样做可以避免脑裂的现象都出现，最大限度地提升集群的高可用性。

只要不少于 discoveryzenminimum_master_nodes 个候选节点存活，选举工作就可以顺利进行，即保持至少一半节点存活。

建议根据数据量衡量。经验值：建议每个分片大小不要超过30GB。

单个索引分片数=数据量÷30g

每个节点建议的单个索引分片数＜3：因为分片分布在同一个服务器上。请求开始竞争相同的硬件资源时, 性能便会逐步下降。

如果该索引分片数过多可以考虑业务需求是否需要分割索引。周表，天表，月表等划分。

注意：除非reindex *** 作，分片数是不可以修改的。

在Elasticsearch中，每个查询在每个分片的单个线程中执行。然而，可以并行处理多个分片，并可以在相同分片上执行多个查询和聚合。

小分片的利弊这意味着，在不涉及高速缓存时，最小查询延迟将取决于数据、查询的类型、分片的大小。查询大量小分片将使得每个分片的处理速度更快，但是随着更多的任务需要按顺序排队和处理，它不一定要比查询较小数量的更大的分片更快。如果有多个并发查询，则有很多小碎片也会降低查询吞吐量。

除非你对系统的健壮性有异常高的要求，比如：银行系统。可以考虑2个副本以上。否则，1个副本足够。

注意：副本数是可以通过配置随时修改的。

根据业务需要选择合适的类型，有利于节省空间和提升精度。Fetch方法只返回要查询的字段，对每组数据做校验，可以避免使用默认mapping的字段类型，增加写入速度、节省空间。

尽量避免使用nested或 parent/child，能不用就不用；nested query慢， parent/child query 更慢，比nested query慢上百倍；因此能在mapping设计阶段搞定的（大宽表设计或采用比较smart的数据结构），就不要用父子关系的mapping。如果一定要使用nested fields，保证nested fields字段不能过多，目前ES默认限制是50。

indexmappingnested_fieldslimit ：50

ES 配置说明

配置文件：elasticsearchyaml。

ES 的配置信息有很多种，大部分配置都可以通过 elasticsearchyaml 和接口的方式进行。

下面我们列出一些比较重要的配置信息：

以上就是关于当查询数据库时，由于数据不断增加，查询变得越来越慢，请问有什么方法可以优化，使查询变快全部的内容，包括:当查询数据库时，由于数据不断增加，查询变得越来越慢，请问有什么方法可以优化，使查询变快、数据库如何优化、ES优化参考【分片、路由】等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！