浅谈数据库查询优化的几种思路

应尽量避免全表扫描，首先应考虑在 where 及 order by ,group by 涉及的列上建立索引

可以帮助选择更好的索引和优化查询语句， 写出更好的优化语句。 通常我们可以对比较复杂的尤其是涉及到多表的 SELECT 语句， 把关键字 EXPLAIN 加到前面， 查看执行计划。例如： explain select * from news

用具体的字段列表代替“*” ， 不要返回用不到的任何字段。

mysql innodb上的理解。

1，不需要的字段会增加数据传输的时间，即使mysql服务器和客户端是在同一台机器上，使用的协议还是tcp，通信也是需要额外的时间。

2，要取的字段、索引的类型，和这两个也是有关系的。举个例子，对于user表，有name和phone的联合索引，select name from user where phone= 12345678912 和 select * from user where phone= 12345678912 ，前者要比后者的速度快，因为name可以在索引上直接拿到，不再需要读取这条记录了。

3，大字段，例如很长的varchar，blob，text。准确来说，长度超过728字节的时候，会把超出的数据放到另外一个地方，因此读取这条记录会增加一次io操作。

比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = unix_timestamp(’2014-05-29’)

使用 procedure analyse()函数对表进行分析， 该函数可以对表中列的数据类型提出优化建议。 能小就用小。 表数据类型第一个原则是： 使用能正确的表示和存储数据的最短类型。 这样可以减少对磁盘空间、 内存、 cpu 缓存的使用。

使用方法： select * from 表名 procedure analyse()

通过拆分表可以提高表的访问效率。 有 2 种拆分方法

1.垂直拆分

把主键和一些列放在一个表中， 然后把主键和另外的列放在另一个表中。 如果一个表中某些列常用， 而另外一些不常用， 则可以采用垂直拆分。

2.水平拆分

根据一列或者多列数据的值把数据行放到二个独立的表中。

创建中间表， 表结构和源表结构完全相同， 转移要统计的数据到中间表， 然后在中间表上进行统计， 得出想要的结果。

选择多核和主频高的 CPU。

使用更大的内存。 将尽量多的内存分配给 MYSQL 做缓存。

4.3.1 使用磁盘阵列

RAID 0 没有数据冗余， 没有数据校验的磁盘陈列。 实现 RAID 0至少需要两块以上的硬盘， 它将两块以上的硬盘合并成一块， 数据连续地分割在每块盘上。

RAID1 是将一个两块硬盘所构成 RAID 磁盘阵列， 其容量仅等于一块硬盘的容量， 因为另一块只是当作数据“镜像”。使用 RAID-0+1 磁盘阵列。 RAID 0+1 是 RAID 0 和 RAID 1 的组合形式。 它在提供与 RAID 1 一样的数据安全保障的同时， 也提供了与 RAID 0 近似的存储性能。

4.3.2 调整磁盘调度算法

选择合适的磁盘调度算法， 可以减少磁盘的寻道时间

对 MySQL 自身的优化主要是对其配置文件 my.cnf 中的各项参数进行优化调整。 如指定 MySQL 查询缓冲区的大小， 指定 MySQL 允许的最大连接进程数等。

它的作用是存储 select 查询的文本及其相应结果。 如果随后收到一个相同的查询， 服务器会从查询缓存中直接得到查询结果。 查询缓存适用的对象是更新不频繁的表， 当表中数据更改后， 查询缓存中的相关条目就会被清空。

1.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：\x0d\x0aselect id from t where num is null\x0d\x0a可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：\x0d\x0aselect id from t where num=0\x0d\x0a2.应尽量避免在 where 子句中使用!=或操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。\x0d\x0a3.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：\x0d\x0aselect id from t where num=10 or num=20\x0d\x0a可以这样查询：\x0d\x0aselect id from t where num=10\x0d\x0aunion all\x0d\x0aselect id from t where num=20\x0d\x0a4.in 和 not in 也要慎用，因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如：\x0d\x0aselect id from t where num in(1,2,3)\x0d\x0a对于连续的数值，能用 between 就不要用 in 了：\x0d\x0aselect id from t where num between 1 and 3\x0d\x0a5.尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。 \x0d\x0a见如下例子： \x0d\x0aSELECT * FROM T1 WHERE NAME LIKE ‘%L%’ \x0d\x0aSELECT * FROM T1 WHERE SUBSTING(NAME,2,1)=’L’ \x0d\x0aSELECT * FROM T1 WHERE NAME LIKE ‘L%’ \x0d\x0a即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。\x0d\x0a6.必要时强制查询优化器使用某个索引，如在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：\x0d\x0aselect id from t where num=@num\x0d\x0a可以改为强制查询使用索引：\x0d\x0aselect id from t with(index(索引名)) where num=@num\x0d\x0a7.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：\x0d\x0aSELECT * FROM T1 WHERE F1/2=100 \x0d\x0a应改为: \x0d\x0aSELECT * FROM T1 WHERE F1=100*2\x0d\x0aSELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)=’5378’ \x0d\x0a应改为: \x0d\x0aSELECT * FROM RECORD WHERE CARD_NO LIKE ‘5378%’\x0d\x0aSELECT member_number, first_name, last_name FROM members \x0d\x0aWHERE DATEDIFF(yy,datofbirth,GETDATE()) >21 \x0d\x0a应改为: \x0d\x0aSELECT member_number, first_name, last_name FROM members \x0d\x0aWHERE dateofbirth ='2005-11-30' and createdate0) \x0d\x0aSELECT SUM(T1.C1) FROM T1WHERE EXISTS( \x0d\x0aSELECT * FROM T2 WHERE T2.C2=T1.C2) \x0d\x0a两者产生相同的结果，但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。

主要内容：match all 等查询类型，多条件组合查询和利用filter进行查询的优化，还简单介绍了排序以及字符串排序

查询所有：

匹配相关field的文本：

将一段搜索的文本使用到多个field上，例如 搜索test_field和test_field1上的匹配test的document

可以放在query和filter里面，例子：查询年龄大于35岁的员工

会将搜索词作为整个词到倒排索引中查询

指定多个term的搜索词：

title匹配xiaomi或者huawei的document

多条件的话，在query下加bool，然后在bool下可以加以下四种条件：

must，must_not，should，filter

每个子查询都会计算一个document针对它的相关度分数，然后bool综合所有分数，合并为一个分数，当然filter是不会计算分数的

当我们不关心检索词频率TF（Term Frequency）对搜索结果排序的影响时，可以使用constant_score将查询语句query或者过滤语句filter包装起来。

如果用上面命令的格式构建查询，查询对象会将所有的条件绑定到一起存储到缓存中；因此如果我们查询人名相同但是出生年份不同的运动员，ElasticSearch无法重用上面查询命令中的任何信息。因此，我们来试着优化一下查询。由于一千个人可能会有一千个人名，所以人名不太适合缓存起来；但是年份比较适合：

我们使用了一个filtered类型的查询对象，查询对象将query元素和filter元素都包含进去了。第一次运行该查询命令后，ElasticSearch就会把filter缓存起来，如果再有查询用到了一样的filter，就会直接用到缓存。就这样，ElasticSearch不必多次加载同样的信息。

一般用在那种特别复杂庞大的搜索下，比如你一下子写了上百行的搜索，这个时候可以先用validate api去验证一下，搜索是否合法

如果对一个string field进行排序，结果往往不准确，因为分词后是多个单词，再排序就不是我们想要的结果了

通常解决方案是，将一个string field建立两次索引，一个分词，用来进行搜索；一个不分词，用来进行排序

创建示例索引

​ 插入数据

​ 开始查询，使用title.raw进行分词，title进行查询

参考的文章：

Elasticsearch查询性能优化 -https://www.jianshu.com/p/6b5ddb594b1b

相关拓展：

为什么Elasticsearch查询变得这么慢了？ 大数据 铭毅天下（公众号同名）-CSDN博客 https://blog.csdn.net/laoyang360/article/details/83048087

---