mysql数据库设计、优化、注意事项（一）

最新推荐文章于 2023-08-03 17:28:34 发布

道哥tim

最新推荐文章于 2023-08-03 17:28:34 发布

阅读量260

点赞数

分类专栏： mysql数据库相关知识文章标签： mysql java

本文链接：https://blog.csdn.net/xixi808/article/details/117022749

版权

mysql数据库相关知识专栏收录该内容

1 篇文章 0 订阅

订阅专栏

mysql数据库设计、优化、注意事项

一、表的设计相关：

1、表设计注意事项：

数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。
字段的长度在最大限度的满足可能的需要的前提下，应该尽可能的设得短一些，这样可以提高查询的效率，而且在建立索引的时候也可以减少资源的消耗。
能够用数字类型的字段尽量选择数字类型而不用字符串类型的（电话号码），这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
对于不可变字符类型char和可变字符类型varchar 都是8000字节,char查询快，但是耗存储空间，varchar查询相对慢一些但是节省存储空间。在设计字段的时候可以灵活选择，例如用户名、密码等长度变化不大的字段可以选择CHAR，对于评论等长度变化大的字段可以选择VARCHAR。
表字段避免null值出现，null值很难查询优化且占用额外的索引空间，推荐默认数字0代替null。
尽量使用INT而非BIGINT，如果非负则加上UNSIGNED（这样数值容量会扩大一倍），当然能使用TINYINT、SMALLINT、MEDIUM_INT更好。
尽量使用TIMESTAMP而非DATETIME，datetime占用6字节，timestamp占用4字节
用整型来存IP
选择合适的字段类型，例如一个status状态字段，一般而言只会存在0、1、2几个不同值，我们可以使用tinyint绝不使用int，int占用空间为tinyint的四倍。又比如性别字段以中文男女分别时可以定义为enum类型，对查询效率有提升

2、索引相关注意事项：

创建索引选择合适的列

（1）查询频繁的列，在where，group by，order by，on从句中出现的列（2）where条件中<，<=，=，>，>=，between，in，以及like 字符串+通配符（%）出现的列（3）长度小的列，索引字段越小越好，因为数据库的存储单位是页，一页中能存下的数据越多越好（4）离散度大（不同的值多）的列，放在联合索引前面。查看离散度，通过统计不同的列值来实现，count越大，离散程度越高
like 以%开头，索引无效；当like前缀没有%，后缀有%时，索引有效。
or语句前后没有同时使用索引。当or左右查询字段只有一个是索引，该索引失效，只有当or左右查询字段均为索引时，才会生效
组合索引，不是使用第一列索引，索引失效。
数据类型出现隐式转化。如varchar不加单引号的话可能会自动转换为int型，使索引无效，产生全表扫描。
在索引列上使用 IS NULL 或 IS NOT NULL操作。索引是不索引空值的，所以这样的操作不能使用索引，可以用其他的办法处理，例如：数字类型，判断大于0，字符串类型设置一个默认值，判断是否等于默认值即可。（此处是错误的！）

解释以上错误：

此处我将重新创建一个emp表

创建新的索引

查看索引

执行SQL语句

由此可发现有使用到索引

总结：在索引列上使用 IS NULL 或 IS NOT NULL操作，索引不一定失效！！！
并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。

二、查询sql优化

在查询时，不要过多地使用通配符如：SELECT * FROM T1 语句，要用到几列就选择几列，如：SELECT COL1,COL2 FROM T1；
应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： SELECT ID FROM T WHERE NUM IS NULL

可以在NUM上设置默认值0，确保表中NUM列没有NULL值，然后这样查询： SELECT ID FROM T WHERE NUM=0
应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行；
应尽量避免在 where 子句中使用 OR来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如： SELECT ID FROM T WHERE NUM=10 OR NUM=20

可以这样查询：

SELECT ID FROM T WHERE NUM=10 UNION ALL SELECT ID FROM T WHERE NUM=20
IN和 NOT IN 也要慎用，因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如： SELECT ID FROM T WHERE NUM IN(1,2,3)

对于连续的数值，能用 BETWEEN就不要用 IN了，如：

SELECT ID FROM T WHERE NUM BETWEEN 1 AND 3
尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。

见如下例子：

SELECT * FROM T1 WHERE NAME LIKE '%L%' ----> 无索引

SELECT * FROM T1 WHERE SUBSTING(NAME,2,1)='L' ----> 无索引

SELECT * FROM T1 WHERE NAME LIKE 'L%' ----> 有索引
```
即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。
```
必要时强制查询优化器使用某个索引，如在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描： SELECT ID FROM T WHERE NUM=@NUM 可以改为强制查询使用索引： SELECT ID FROM T WITH(INDEX(索引名)) WHERE NUM=@NUM
应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如： SELECT * FROM T1 WHERE F1/2=100

应改为:

SELECT * FROM T1 WHERE F1=100*2

SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO,1,4)='5378'

应改为:

SELECT * FROM RECORD WHERE CARD_NO LIKE '5378%'

SELECT member_number, first_name, last_name FROM members WHERE DATEDIFF(yy,datofbirth,GETDATE()) > 21

应改为: SELECT member_number, first_name, last_name FROM members WHERE dateofbirth < DATEADD(yy,-21,GETDATE())

即：任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如： select id from t where substring(name,1,3)='abc' ---->name以abc开头的id select id from t where datediff(day,createdate,'2005-11-30')=0 ---->'2005-11-30'生成的id 应改为: select id from t where name like 'abc%' select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
很多时候用 exists是一个好的选择，例：

SELECT NUM FROM A WHERE NUM IN(SELECT NUM FROM B) 用下面的语句替换： SELECT NUM FROM A WHERE EXISTS(SELECT 1 FROM B WHERE NUM=A.NUM)

SELECT SUM(T1.C1) FROM T1 WHERE(SELECT COUNT(*)FROM T2 WHERE T2.C2=T1.C2>0)

用下面的语句替换： SELECT SUM(T1.C1) FROM T1WHERE EXISTS(SELECT * FROM T2 WHERE T2.C2=T1.C2)

两者产生相同的结果，但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。

如果你想校验表里是否存在某条纪录，不要用count()那样效率很低，而且浪费服务器资源。可以用EXISTS代替。如： IF (SELECT COUNT() FROM table_name WHERE column_name = 'xxx') 可以写成： IF EXISTS (SELECT * FROM table_name WHERE column_name = 'xxx')

经常需要写一个T_SQL语句比较一个父结果集和子结果集，从而找到是否存在在父结果集中有而在子结果集中没有的记录，如： SELECT a.hdr_key FROM hdr_tbl a ---- tbl a 表示tbl用别名a代替

WHERE NOT EXISTS (SELECT * FROM dtl_tbl b WHERE a.hdr_key = b.hdr_key)

SELECT a.hdr_key FROM hdr_tbl a

LEFT JOIN dtl_tbl b ON a.hdr_key = b.hdr_key WHERE b.hdr_key IS NULL

SELECT hdr_key FROM hdr_tbl

WHERE hdr_key NOT IN (SELECT hdr_key FROM dtl_tbl)

三种写法都可以得到同样正确的结果，但是效率依次降低。
避免频繁创建和删除临时表，以减少系统表资源的消耗。
临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。

注意：SELECT INTO 语句会导致表锁定，阻止其他用户访问该表
尽量避免大事务操作，提高系统并发能力。
尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。
避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。
1. 例如: SELECT name FROM employee WHERE salary > 60000
2. 在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。
充分利用连接条件，在某种情况下，两个表之间可能不只一个的连接条件，这时在 WHERE 子句中将连接条件完整的写上，有可能大大提高查询速度。
1. 例： SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO
  
  SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD B WHERE A.CARD_NO = B.CARD_NO
  
  AND A.ACCOUNT_NO=B.ACCOUNT_NO
  
  第二句将比第一句执行快得多。
使用视图加速查询 把表的一个子集进行排序并创建视图，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。例如：

SELECT cust.name，rcvbles.balance，……other columns

FROM cust，rcvbles

WHERE cust.customer_id = rcvlbes.customer_id

AND rcvblls.balance>0

AND cust.postcode>98000

ORDER BY cust.name

如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个视图中，并按客户的名字进行排序： CREATE VIEW DBO.V_CUST_RCVLBES

AS

SELECT cust.name，rcvbles.balance，……other columns

FROM cust，rcvbles

WHERE cust.customer_id = rcvlbes.customer_id

AND rcvblls.balance>0

ORDER BY cust.name

然后以下面的方式在视图中查询： SELECT * FROM V_CUST_RCVLBES WHERE postcode>98000

视图中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。
能用DISTINCT的就不用GROUP BY SELECT OrderID FROM Details WHERE UnitPrice > 10 GROUP BY OrderID

可改为：

SELECT DISTINCT OrderID FROM Details WHERE UnitPrice > 10
能用UNION ALL就不要用UNION UNION ALL不执行SELECT DISTINCT函数，这样就会减少很多不必要的资源
尽量不要用SELECT INTO语句 SELECT INOT 语句会导致表锁定，阻止其他用户访问该表。

上面我们提到的是一些基本的提高查询速度的注意事项,但是在更多的情况下,往往需要反复试验比较不同的语句以得到最佳方案。最好的方法当然是测试，看实现相同功能的SQL语句哪个执行时间最少，但是数据库中如果数据量很少，是比较不出来的，这时可以用查看执行计划，即：把实现相同功能的多条SQL语句考到查询分析器，表扫描次数（这两个对性能影响最大），总体上看询成本百分比即可。

道哥tim

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
mysql数据库设计、优化、注意事项（一）

mysql数据库设计、优化、注意事项一、表的设计相关：1、表设计注意事项：数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。字段的长度在最大限度的满足可能的需要的前提下，应该尽可能的设得短一些，这样可以提高查询的效率，而且在建立索引的时候也可以减少资源的消耗。能够用数字类型的字段尽量选择数字类型而不用字符串类型的（电话号码），这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接回.
复制链接

扫一扫

专栏目录