数据库优化面试题 - yan束子

1.实践中如何优化mysql

1) SQL语句及索引的优化

2) 数据库表结构的优化

3) 系统配置的优化

4) 硬件优化

 

2.索引的底层实现原理和优化

在 DB2 数据库中索引采用的是 B+ 树的结构，索引的叶子节点上包含索引键的值和一个指向数据地址的指针。DB2 先查询索引，然后通过索引里记录的指针，直接访问表的数据页。

B+树。B+树是应数据库所需而出现的一种B树的变形树。

B+树的特点：

（1）所有叶节点包含全部关键字及指向相应记录的指针，而且叶节点中将关键字按大小顺序排列，并且相邻叶节点按大小顺序相互链接起来。

（2）所有分支节点（可看做索引的索引）中仅包含它的各个子节点（即下一级的索引块）中关键字的最大值即指向其子节点的指针。

（3）B+树中，叶节点包含信息，所有非叶结点仅起到索引作用，非叶节点中的每个索引项只含有对应子树的最大关键字和指向该子树的指针，不含有该关键字对应记录的存储地址。

（4）叶节点包含了所有的关键字，即在非叶节点出现的关键字也会出现在叶子节点中。

B+树有两个头指针，一个指向根节点，另一个指向关键字最小的叶节点。B+树进行两种查找运算：从最小关键字开始的顺序查找，另一种从根节点开始的多路查找。

原理：叶子节点是按关键字大小顺序排列，且增加了指向下一个叶子节点的指针。

优化：InnoDB建议大部分表使用默认的自增的主键作为索引

MsSql、DB2使用的是B+Tree，Oracle及Sysbase使用的是B-Tree

SQL语句的优化

1) 尽量避免耗时操作。

带有DISTINCT,UNION,MINUS,INTERSECT,ORDER BY的SQL语句会启动SQL引 执行，耗费资源的排序(SORT)功能。DISTINCT需要一次排序操作, 而其他的至少需要执行两次排序

2) 如果无需排除重复值或是操作集无重复则用UNION ALL， UNION更费事（因为要比较）

UNION因为会将各查询子集的记录做比较，故比起UNION ALL ，通常速度都会慢上许多。一般来说，如果使用UNION ALL能满足要求的话， 务必使用UNION ALL。还有一种情况大家可能会忽略掉，就是虽然要求几个子集的并集需要过滤掉重复记录，但由于脚本的特殊性，不可能存在重复记录，这时便应该使用UNION ALL，如xx模块的某个查询程序就曾经存在这种情况，见，由于语句的特殊性，在这个脚本中几个子集的记录绝对不可能重复，故可以改用UNION ALL）连接操作

3) 避免在WHERE子句中使用in，not  in，or 或者having。
可以使用 exist 和not exist代替 in和not in。
可以使用表链接代替 exist。
Having可以用where代替，如果无法代替可以分两步处理。
例子

[java] view plain copy

 

1. SELECT * FROM ORDERS WHERE CUSTOMER_NAME NOT IN  
2. (SELECT CUSTOMER_NAME FROM CUSTOMER)  

优化

 

[java] view plain copy

 

1. SELECT * FROM ORDERS WHERE CUSTOMER_NAME not exist  
2. (SELECT CUSTOMER_NAME FROM CUSTOMER)  

4) 不要在建立的索引的数据列上进行下列操作:
（1）避免对索引字段进行计算操作

（2）避免在索引字段上使用not，<>，!=

（3）避免在索引列上使用IS NULL和IS NOT NULL

（4）避免在索引列上出现数据类型转换

（5）避免在索引字段上使用函数

例如：where trunc(create_date)=trunc(:date1)
虽然已对create_date 字段建了索引，但由于加了TRUNC，使得索引无法用上。此处正确的写法应该是
where create_date>=trunc(:date1) and create_date

（6）避免建立索引的列中使用空值。

5) 查询的模糊匹配

尽量避免在一个复杂查询里面使用 LIKE \'%parm1%\'—— 红色标识位置的百分号会导致相关列的索引无法使用，最好不要用。

解决办法:

其实只需要对该脚本略做改进，查询速度便会提高近百倍。改进方法如下：

a、修改前台程序——把查询条件的供应商名称一栏由原来的文本输入改为下拉列表，用户模糊输入供应商名称时，直接在前台就帮忙定位到具体的供应商，这样在调用后台程序时，这列就可以直接用等于来关联了。

b、直接修改后台——根据输入条件，先查出符合条件的供应商，并把相关记录保存在一个临时表里头，然后再用临时表去做复杂关联

6) 避免使用临时表
(1)除非却有需要，否则应尽量避免使用临时表，相反，可以使用表变量代替;
(2)大多数时候(99%)，表变量驻扎在内存中，因此速度比临时表更快，临时表驻扎在TempDb数据库中，因此临时表上的操作需要跨数据库通信，速度自然慢。

可以使用联合(UNION)来代替手动创建的临时表

MySQL 从 4.0 的版本开始支持 UNION 查询，它可以把需要使用临时表的两条或更多的 SELECT 查询合并的一个查询中。在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。使用 UNION 来创建查询的时候，我们只需要用UNION作为关键字把多个SELECT语句连接起来就可以了，要注意的是所有 SELECT 语句中的字段数目要想同。下面的例子就演示了一个使用 UNION的查询。

代码如下:

 

[java] view plain copy

 

1. SELECT Name, Phone FROM client UNION SELECT Name, BirthDate FROM author  
2. UNION  
3. SELECT Name, Supplier FROM product  

7) 尽量少做重复的工作
尽量减少无效工作，但是这一点的侧重点在客户端程序，需要注意的如下：
A、 控制同一语句的多次执行，特别是一些基础数据的多次执行是很多程序员很少注意的
B、减少多次的数据转换，也许需要数据转换是设计的问题，但是减少次数是程序员可以做到的。
C、杜绝不必要的子查询和连接表，子查询在执行计划一般解释成外连接，多余的连接表带来额外的开销。
D、合并对同一表同一条件的多次UPDATE，比如
UPDATE EMPLOYEE SET FNAME=\'HAIWER\' WHERE EMP_ID=\' VPA30890F\'
UPDATE EMPLOYEE SET LNAME=\'YANG\' WHERE EMP_ID=\' VPA30890F\'
这两个语句应该合并成以下一个语句
UPDATE EMPLOYEE SET FNAME=\'HAIWER\',LNAME=\'YANG\'
WHERE EMP_ID=\' VPA30890F\'
E、UPDATE操作不要拆成DELETE操作+INSERT操作的形式，虽然功能相同，但是性能差别是很大的。
F、不要写一些没有意义的查询，比如
SELECT * FROM EMPLOYEE WHERE 1=2

Where后面的原则

第一个原则：在where子句中应把最具限制性的条件放在最前面。

第二个原则：where子句中字段的顺序应和索引中字段顺序一致。

select field3,field4 from tb where upper(field2)=\'RMN\'不使用索引。
如果一个表有两万条记录，建议不使用函数；如果一个表有五万条以上记录，严格禁止使用函数！两万条记录以下没有限制。

 

3.什么情况下设置了索引但无法使用，索引无效

1) 以”%”开头的LIKE语句，模糊匹配：红色标识位置的百分号会导致相关列的索引无法使用

2) Or语句前后没有同时使用索引

3) 数据类型出现隐式转化（如varchar不加单引号的话可能会自动转换为int型，会使索引无效，产生全表扫描。）

4) 在索引列上使用IS NULL 或IS NOT NULL操作。索引是不索引空值的，所以这样的操作不能使用索引，可以用其他的办法处理，例如：数字类型，判断大于0，字符串类型设置一个默认值，判断是否等于默认值即可

5) 在索引字段上使用not，<>，!=，eg<> 操作符（不等于）：不等于操作符是永远不会用到索引的，因此对它的处理只会产生全表扫描。 用其它相同功能的操作运算代替，如 a<>0 改为 a>0 or a<0

6) 对索引字段进行计算操作

7) 在索引字段上使用函数

 

一、SQL语句优化
（1）使用limit对查询结果的记录进行限定
（2）避免select *，将需要查找的字段列出来
（3）使用连接（join）来代替子查询
（4）拆分大的delete或insert语句
二、选择合适的数据类型
（1）使用可存下数据的最小的数据类型，整型 < date,time < char,varchar < blob
（2）使用简单的数据类型，整型比字符处理开销更小，因为字符串的比较更复杂。如，int类型存储时间类型，bigint类型转ip函数
（3）使用合理的字段属性长度，固定长度的表会更快。使用enum、char而不是varchar
（4）尽可能使用not null定义字段
（5）尽量少用text，非用不可最好分表
三、选择合适的索引列
（1）查询频繁的列，在where，group by，order by，on从句中出现的列
（2）where条件中<，<=，=，>，>=，between，in，以及like 字符串+通配符（%）出现的列
（3）长度小的列，索引字段越小越好，因为数据库的存储单位是页，一页中能存下的数据越多越好
（4）离散度大（不同的值多）的列，放在联合索引前面。查看离散度，通过统计不同的列值来实现，count越大，离散程度越高：
mysql> SELECT COUNT(DISTINCT column_name) FROM table_name;
四、使用命令分析
（1）SHOW查看状态
1.显示状态信息
mysql> SHOW [SESSION|GLOBAL] STATUS LIKE \'%Status_name%\';
session（默认）：取出当前窗口的执行
global：从mysql启动到现在
（a）查看查询次数（插入次数com_insert、修改次数com_insert、删除次数com_delete）
mysql> SHOW STATUS LIKE \'com_select\';
（b）查看连接数(登录次数)
mysql> SHOW STATUS LIKE \'connections\';
（c）数据库运行时间
mysql> SHOW STATUS LIKE \'uptime\';
（d）查看慢查询次数
mysql> SHOW STATUS LIKE \'slow_queries\';
（e）查看索引使用的情况：
mysql> SHOW STATUS LIKE \'handler_read%\';
handler_read_key：这个值越高越好，越高表示使用索引查询到的次数。
handler_read_rnd_next：这个值越高，说明查询低效。
2.显示系统变量
mysql> SHOW VARIABLES LIKE \'%Variables_name%\';
3.显示InnoDB存储引擎的状态
mysql> SHOW ENGINE INNODB STATUS;
（2）EXPLAIN分析查询
mysql> EXPLAIN SELECT column_name FROM table_name;
explain查询sql执行计划，各列含义：
table：表名；
type：连接的类型
-const：主键、索引；
-eq_reg：主键、索引的范围查找；
-ref：连接的查找（join）
-range：索引的范围查找；
-index：索引的扫描；
-all：全表扫描；
possible_keys：可能用到的索引；
key：实际使用的索引；
key_len：索引的长度，越短越好；
ref：索引的哪一列被使用了，常数较好；
rows：mysql认为必须检查的用来返回请求数据的行数；
extra：using filesort、using temporary（常出现在使用order by时）时需要优化。
-Using filesort 额外排序。看到这个的时候，查询就需要优化了
-Using temporary 使用了临时表。看到这个的时候，也需要优化
（3）PROFILING分析SQL语句
1.开启profile。查看当前SQL执行时间
mysql> SET PROFILING=ON;
mysql> SHOW profiles;
2.查看所有用户的当前连接。包括执行状态、是否锁表等
mysql> SHOW processlist;
（4）PROCEDURE ANALYSE()取得建议
通过分析select查询结果对现有的表的每一列给出优化的建议
mysql> SELECT column_name FROM table_name PROCEDURE ANALYSE();
（5）OPTIMIZE TABLE回收闲置的数据库空间
mysql> OPTIMIZE TABLE table_name;
对于MyISAM表，当表上的数据行被删除时，所占据的磁盘空间并没有立即被回收，使用命令后这些空间将被回收，并且对磁盘上的数据行进行重排（注意：是磁盘上，而非数据库）。
对于InnoDB表，OPTIMIZE TABLE被映射到ALTER TABLE上，这会重建表。重建操作能更新索引统计数据并释放成簇索引中的未使用的空间。
只需在批量删除数据行之后，或定期（每周一次或每月一次）进行一次数据表优化操作即可，只对那些特定的表运行。
（6）REPAIR TABLE修复被破坏的表
mysql> REPAIR TABLE table_name;
（7）CHECK TABLE检查表是否有错误
mysql> CHECK TABLE table_name;

4.如何设计一个高并发的系统

1) 数据库的优化，包括合理的事务隔离级别、SQL语句优化、索引优化

2) 使用缓存、尽量减少数据库IO

3) 分布式数据库、分布式缓存

4) 服务器的负载均衡