MySQL 知识点整理

什么是存储过程？有哪些优缺点？

存储过程就像我们编程语言中的函数一样，封装了我们的代码(PLSQL、T-SQL)。

优点

• 能够将代码封装起来

• 保存在数据库之中

• 让编程语言进行调用

• 存储过程是一个预编译的代码块，执行效率比较高

• 一个存储过程替代大量 T_SQL 语句 ，可以降低网络通信量，提高通信速率

缺点

• 每个数据库的存储过程语法几乎都不一样，十分难以维护（不通用）

• 业务逻辑放在数据库上，难以迭代

视图的作用，视图可以更改么

视图是虚拟的表，与包含数据的表不一样，视图只包含使用时动态检索数据的查询；不包含任何列或数据。使用视图可以简化复杂的 sql 操作，隐藏具体的细节，保护数据；视图创建后，可以使用与表相同的方式利用它们。

视图不能被索引，也不能有关联的触发器或默认值，如果视图本身内有 order by 则对视图再次 order by 将被覆盖。

创建视图：create view XXX as XXXXXXXXXXXXXX;

对于某些视图比如未使用联结子查询分组聚集函数 Distinct Union 等，是可以对其更新的，对视图的更新将对基表进行更新；但是视图主要用于简化检索，保护数据，并不用于更新，而且大部分视图都不可以更新。

从 innodb 的索引结构分析，为什么索引的 key 长度不能太长

key 太长会导致一个页当中能够存放的 key 的数目变少，间接导致索引树的页数目变多，索引层次增加，从而影响整体查询变更的效率。

MySQL 的数据如何恢复到任意时间点

恢复到任意时间点以定时的做全量备份，以及备份增量的 binlog 日志为前提。恢复到任意时间点首先将全量备份恢复之后，再此基础上回放增加的 binlog 直至指定的时间点

索引的工作原理及其种类

数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询、更新数据库表中数据。索引的实现通常使用 B 树及其变种 B+树。

在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。

为表设置索引要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。

图展示了一种可能的索引方式。左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址（注意逻辑上相邻的记录在磁盘上也并不是一定物理相邻的）。为了加快 Col2 的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在 O(log2n)的复杂度内获取到相应数据。

创建索引可以大大提高系统的性能。

第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。

第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。

第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。

第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。

第五，通过使用索引，可以在查询的过程中，使用优化隐藏器，提高系统的性能。

也许会有人要问：增加索引有如此多的优点，为什么不对表中的每一个列创建一个索引呢？因为，增加索引也有许多不利的方面。

第一，创建索引和维护索引要耗费时间，这种时间随着数据量的增加而增加。

第二，索引需要占物理空间，除了数据表占数据空间之外，每一个索引还要占一定的物理空间，如果要建立聚簇索引，那么需要的空间就会更大。

第三，当对表中的数据进行增加、删除和修改的时候，索引也要动态的维护，这样就降低了数据的维护速度。

索引是建立在数据库表中的某些列的上面。在创建索引的时候，应该考虑在哪些列上可以创建索引，在哪些列上不能创建索引。一般来说，应该在这些列上创建索引：在经常需要搜索的列上，可以加快搜索的速度；在作为主键的列上，强制该列的唯一性和组织表中数据的排列结构；在经常用在连接的列上，这些列主要是一些外键，可以加快连接的速度；在经常需要根据范围进行搜索的列上创建索引，因为索引已经排序，其指定的范围是连续的；在经常需要排序的列上创建索引，因为索引已经排序，这样查询可以利用索引的排序，加快排序查询时间；在经常使用在 WHERE 子句中的列上面创建索引，加快条件的判断速度。

同样，对于有些列不应该创建索引。一般来说，不应该创建索引的的这些列具有下列特点：

第一，对于那些在查询中很少使用或者参考的列不应该创建索引。这是因为，既然这些列很少使用到，因此有索引或者无索引，并不能提高查询速度。相反，由于增加了索引，反而降低了系统的维护速度和增大了空间需求。

第二，对于那些只有很少数据值的列也不应该增加索引。这是因为，由于这些列的取值很少，例如人事表的性别列，在查询的结果中，结果集的数据行占了表中数据行的很大比例，即需要在表中搜索的数据行的比例很大。增加索引，并不能明显加快检索速度。

第三，对于那些定义为 text, image 和 bit 数据类型的列不应该增加索引。这是因为，这些列的数据量要么相当大，要么取值很少。

第四，当修改性能远远大于检索性能时，不应该创建索引。这是因为，修改性能和检索性能是互相矛盾的。当增加索引时，会提高检索性能，但是会降低修改性能。当减少索引时，会提高修改性能，降低检索性能。因此，当修改性能远远大于检索性能时，不应该创建索引。

根据数据库的功能，可以在数据库设计器中创建三种索引：唯一索引、主键索引和聚集索引。

唯一索引

唯一索引是不允许其中任何两行具有相同索引值的索引。

当现有数据中存在重复的键值时，大多数数据库不允许将新创建的唯一索引与表一起保存。数据库还可能防止添加将在表中创建重复键值的新数据。例如，如果在 employee 表中职员的姓(lname)上创建了唯一索引，则任何两个员工都不能同姓。

主键索引 数据库表经常有一列或列组合，其值唯一标识表中的每一行。该列称为表的主键。 在数据库关系图中为表定义主键将自动创建主键索引，主键索引是唯一索引的特定类型。该索引要求主键中的每个值都唯一。当在查询中使用主键索引时，它还允许对数据的快速访问。 聚集索引 在聚集索引中，表中行的物理顺序与键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引。

如果某索引不是聚集索引，则表中行的物理顺序与键值的逻辑顺序不匹配。与非聚集索引相比，聚集索引通常提供更快的数据访问速度。

局部性原理与磁盘预读 由于存储介质的特性，磁盘本身存取就比主存慢很多，再加上机械运动耗费，磁盘的存取速度往往是主存的几百分分之一，因此为了提高效率，要尽量减少磁盘 I/O。为了达到这个目的，磁盘往往不是严格按需读取，而是每次都会预读，即使只需要一个字节，磁盘也会从这个位置开始，顺序向后读取一定长度的数据放入内存。这样做的理论依据是计算机科学中著名的局部性原理：当一个数据被用到时，其附近的数据也通常会马上被使用。程序运行期间所需要的数据通常比较集中。

由于磁盘顺序读取的效率很高（不需要寻道时间，只需很少的旋转时间），因此对于具有局部性的程序来说，预读可以提高 I/O 效率。

预读的长度一般为页（page）的整倍数。页是计算机管理存储器的逻辑块，硬件及操作系统往往将主存和磁盘存储区分割为连续的大小相等的块，每个存储块称为一页（在许多操作系统中，页得大小通常为 4k），主存和磁盘以页为单位交换数据。当程序要读取的数据不在主存中时，会触发一个缺页异常，此时系统会向磁盘发出读盘信号，磁盘会找到数据的起始位置并向后连续读取一页或几页载入内存中，然后异常返回，程序继续运行。

B-/+Tree 索引的性能分析 到这里终于可以分析 B-/+Tree 索引的性能了。

上文说过一般使用磁盘 I/O 次数评价索引结构的优劣。先从 B-Tree 分析，根据 B-Tree 的定义，可知检索一次最多需要访问 h 个节点。数据库系统的设计者巧妙利用了磁盘预读原理，将一个节点的大小设为等于一个页，这样每个节点只需要一次 I/O 就可以完全载入。为了达到这个目的，在实际实现 B-Tree 还需要使用如下技巧：

每次新建节点时，直接申请一个页的空间，这样就保证一个节点物理上也存储在一个页里，加之计算机存储分配都是按页对齐的，就实现了一个 node 只需一次 I/O。

B-Tree 中一次检索最多需要 h-1 次 I/O（根节点常驻内存），渐进复杂度为 O(h)=O(logdN)。一般实际应用中，出度 d 是非常大的数字，通常超过 100，因此 h 非常小（通常不超过 3）。

而红黑树这种结构，h 明显要深的多。由于逻辑上很近的节点（父子）物理上可能很远，无法利用局部性，所以红黑树的 I/O 渐进复杂度也为 O(h)，效率明显比 B-Tree 差很多。

综上所述，用 B-Tree 作为索引结构效率是非常高的。

drop,delete 与 truncate 的区别

drop 直接删掉表 truncate 删除表中数据，再插入时自增长 id 又从 1 开始 delete 删除表中数据，可以加 where 字句。

1. DELETE 语句执行删除的过程是每次从表中删除一行，并且同时将该行的删除操作作为事务记录在日志中保存以便进行进行回滚操作。TRUNCATE TABLE 则一次性地从表中删除所有的数据并不把单独的删除操作记录记入日志保存，删除行是不能恢复的。并且在删除的过程中不会激活与表有关的删除触发器。执行速度快。

2. 表和索引所占空间。当表被 TRUNCATE 后，这个表和索引所占用的空间会恢复到初始大小，而 DELETE 操作不会减少表或索引所占用的空间。drop 语句将表所占用的空间全释放掉。

3. 一般而言，drop > truncate > delete

4. 应用范围。TRUNCATE 只能对 TABLE；DELETE 可以是 table 和 view

5. TRUNCATE 和 DELETE 只删除数据，而 DROP 则删除整个表（结构和数据）。

6. truncate 与不带 where 的 delete ：只删除数据，而不删除表的结构（定义）drop 语句将删除表的结构被依赖的约束（constrain),触发器（trigger)索引（index);依赖于该表的存储过程/函数将被保留，但其状态会变为：invalid。

7. delete 语句为 DML（Data Manipulation Language),这个操作会被放到 rollback segment 中,事务提交后才生效。如果有相应的 tigger,执行的时候将被触发。

8. truncate、drop 是 DDL（Data Define Language),操作立即生效，原数据不放到 rollback segment 中，不能回滚

9. 在没有备份情况下，谨慎使用 drop 与 truncate。要删除部分数据行采用 delete 且注意结合 where 来约束影响范围。回滚段要足够大。要删除表用 drop;若想保留表而将表中数据删除，如果于事务无关，用 truncate 即可实现。如果和事务有关，或老是想触发 trigger,还是用 delete。

10. Truncate table 表名 速度快,而且效率高,因为: truncate table 在功能上与不带 WHERE 子句的 DELETE 语句相同：二者均删除表中的全部行。但 TRUNCATE TABLE 比 DELETE 速度快，且使用的系统和事务日志资源少。DELETE 语句每次删除一行，并在事务日志中为所删除的每行记录一项。TRUNCATE TABLE 通过释放存储表数据所用的数据页来删除数据，并且只在事务日志中记录页的释放。

11. TRUNCATE TABLE 删除表中的所有行，但表结构及其列、约束、索引等保持不变。新行标识所用的计数值重置为该列的种子。如果想保留标识计数值，请改用 DELETE。如果要删除表定义及其数据，请使用 DROP TABLE 语句。

12. 对于由 FOREIGN KEY 约束引用的表，不能使用 TRUNCATE TABLE，而应使用不带 WHERE 子句的 DELETE 语句。由于 TRUNCATE TABLE 不记录在日志中，所以它不能激活触发器。

主键 超键 候选键 外键是什么

超键(super key): 在关系中能唯一标识元组的属性集称为关系模式的超键

候选键(candidate key): 不含有多余属性的超键称为候选键。也就是在候选键中，若再删除属性，就不是键了！

主键(primary key): 用户选作元组标识的一个候选键程序主键

外键(foreign key)：如果关系模式 R 中属性 K 是其它模式的主键，那么 k 在模式 R 中称为外键

三个范式是什么

第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。

第二范式（2NF）：数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。

第三范式（3NF）：在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。所谓传递函数依赖，指的是如果存在"A → B → C"的决定关系，则 C 传递函数依赖于 A。因此，满足第三范式的数据库表应该不存在如下依赖关系： 关键字段 → 非关键字段 x → 非关键字段 y

总结一下：

首先要明确的是：满足着第三范式，那么就一定满足第二范式、满足着第二范式就一定满足第一范式

第一范式：字段是最小的的单元不可再分

* 学生信息组成学生信息表，有年龄、性别、学号等信息组成。这些字段都不可再分，所以它是满足第一范式的

第二范式：满足第一范式,表中的字段必须完全依赖于全部主键而非部分主键。

其他字段组成的这行记录和主键表示的是同一个东西，而主键是唯一的，它们只需要依赖于主键，也就成了唯一的

学号为 1024 的同学，姓名为 Java3y，年龄是 22 岁。姓名和年龄字段都依赖着学号主键。

第三范式：满足第二范式，非主键外的所有字段必须互不依赖

就是数据只在一个地方存储，不重复出现在多张表中，可以认为就是消除传递依赖

比如，我们大学分了很多系（中文系、英语系、计算机系……），这个系别管理表信息有以下字段组成：系编号，系主任，系简介，系架构。那我们能不能在学生信息表添加系编号，系主任，系简介，系架构字段呢？不行的，因为这样就冗余了，非主键外的字段形成了依赖关系(依赖到学生信息表了)！正确的做法是：学生表就只能增加一个系编号字段。

什么是视图？以及视图的使用场景有哪些

视图是一种基于数据表的一种虚表

• 视图是一种虚表

• 视图建立在已有表的基础上, 视图赖以建立的这些表称为基表

• 向视图提供数据内容的语句为 SELECT 语句,可以将视图理解为存储起来的 SELECT 语句

• 视图向用户提供基表数据的另一种表现形式

• 视图没有存储真正的数据，真正的数据还是存储在基表中

• 程序员虽然操作的是视图，但最终视图还会转成操作基表

• 一个基表可以有 0 个或多个视图

有的时候，我们可能只关系一张数据表中的某些字段，而另外的一些人只关系同一张数据表的某些字段，那么把全部的字段都都显示给他们看，这是不合理的。我们应该做到：他们想看到什么样的数据，我们就给他们什么样的数据，一方面就能够让他们只关注自己的数据，另一方面，我们也保证数据表一些保密的数据不会泄露出来。

我们在查询数据的时候，常常需要编写非常长的 SQL 语句，几乎每次都要写很长很长，上面已经说了，视图就是基于查询的一种虚表，也就是说，视图可以将查询出来的数据进行封装，那么我们在使用的时候就会变得非常方便。

值得注意的是：使用视图可以让我们专注与逻辑，但不提高查询效率。

drop、delete 与 truncate 分别在什么场景之下使用

drop table

• 属于 DDL

• 不可回滚

• 不可带 where

• 表内容和结构删除

• 删除速度快

truncate table

• 属于 DDL

• 不可回滚

• 不可带 where

• 表内容删除

• 删除速度快

delete from

• 属于 DML

• 可回滚

• 可带 where

• 表结构在，表内容要看 where 执行的情况

• 删除速度慢,需要逐行删除

使用场景

1. 不再需要一张表的时候，用 drop

2. 想删除部分数据行时候，用 delete，并且带上 where 子句

3. 保留表而删除所有数据的时候用 truncate

rowid 的特点

1. 位于每个表中，但表面上看不见，例如：desc emp是看不见的

2. 只有在select中，显示写出rowid，方可看见

3. 它与每个表绑定在一起，表亡，该表的rowid亡，二张表rownum可以相同，但rowid必须是唯一的

4. rowid是 18 位大小写加数字混杂体，唯一表代该条记录在 DBF 文件中的位置

5. rowid可以参与=/like比较时，用''单引号将rowid的值包起来，且区分大小写

6. rowid是联系表与 DBF 文件的桥梁

索引特点

1. 索引一旦建立, Oracle 管理系统会对其进行自动维护, 而且由 Oracle 管理系统决定何时使用索引

2. 用户不用在查询语句中指定使用哪个索引

3. 在定义primary key或unique约束后系统自动在相应的列上创建索引

4. 用户也能按自己的需求，对指定单个字段或多个字段，添加索引

   
   

   需要注意的是：Oracle 是自动帮我们管理索引的，并且如果我们指定了primary key或者unique约束，系统会自动在对应的列上创建索引

索引分类：

• 唯一索引：唯一索引不允许两行具有相同的索引值

• 主键索引：为表定义一个主键将自动创建主键索引，主键索引是唯一索引的特殊类型。主键索引要求主键中的每个值是唯一的，并且不能为空

• 聚集索引(Clustered)：表中各行的物理顺序与键值的逻辑（索引）顺序相同，每个表只能有一个

• 非聚集索引(Non-clustered)：非聚集索引指定表的逻辑顺序。数据存储在一个位置，索引存储在另一个位置，索引中包含指向数据存储位置的指针。可以有多个，小于 249 个

数据库的乐观锁和悲观锁是什么

确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性，乐观锁和悲观锁是并发控制主要采用的技术手段。

• 悲观锁：假定会发生并发冲突，屏蔽一切可能违反数据完整性的操作

• 在查询完数据的时候就把事务锁起来，直到提交事务

• 实现方式：使用数据库中的锁机制

• 乐观锁：假设不会发生并发冲突，只在提交操作时检查是否违反数据完整性。

• 在修改数据的时候把事务锁起来，通过 version 的方式来进行锁定

• 实现方式：使用 version 版本或者时间戳

MySQL 存储引擎

• Innodb 引擎，Innodb 引擎提供了对数据库 ACID 事务的支持。并且还提供了行级锁和外键的约束。它的设计的目标就是处理大数据容量的数据库系统。

• MyIASM 引擎(原本 Mysql 的默认引擎),不提供事务的支持，也不支持行级锁和外键。

• MEMORY 引擎：所有的数据都在内存中，数据的处理速度快，但是安全性不高

MyIASM 和 Innodb 两种引擎所使用的索引的数据结构是什么

都是 B+树。

• MyIASM 引擎，B+树的数据结构中存储的内容实际上是实际数据的地址值。也就是说它的索引和实际数据是分开的，只不过使用索引指向了实际数据。这种索引的模式被称为非聚集索引。

• Innodb 引擎的索引的数据结构也是 B+树，只不过数据结构中存储的都是实际的数据，这种索引有被称为聚集索引。

varchar 和 char 的区别

Char 是一种固定长度的类型，varchar 是一种可变长度的类型

mysql 有关权限的表都有哪几个

MySQL 服务器通过权限表来控制用户对数据库的访问，权限表存放在 mysql 数据库里，由mysql_install_db脚本初始化。这些权限表分别user，db，table_priv，columns_priv和host。下面分别介绍一下这些表的结构和内容：

• user 权限表：记录允许连接到服务器的用户帐号信息，里面的权限是全局级的。

• db 权限表：记录各个帐号在各个数据库上的操作权限。

• table_priv 权限表：记录数据表级的操作权限。

• columns_priv 权限表：记录数据列级的操作权限。

• host 权限表：配合 db 权限表对给定主机上数据库级操作权限作更细致的控制。这个权限表不受GRANT和REVOKE语句的影响。

数据表损坏的修复方式有哪些？

使用 myisamchk 来修复，具体步骤：

1. 修复前将 mysql 服务停止。

2. 打开命令行方式，然后进入到 mysql 的/bin 目录。

3. 执行myisamchk –recover数据库所在路径/*.MYI
   

使用repair table 或者 OPTIMIZE table命令来修复，REPAIR TABLE table_name 修复表 OPTIMIZE TABLE table_name 优化表 REPAIR TABLE 用于修复被破坏的表。

OPTIMIZE TABLE 用于回收闲置的数据库空间，当表上的数据行被删除时，所占据的磁盘空间并没有立即被回收，使用了OPTIMIZE TABLE命令后这些空间将被回收，并且对磁盘上的数据行进行重排（注意：是磁盘上，而非数据库）

MySQL 中 InnoDB 引擎的行锁是通过加在什么上完成

InnoDB 是基于索引来完成行锁

例: select * from tab_with_index where id = 1 for update;

for update可以根据条件来完成行锁锁定,并且 id 是有索引键的列，如果 id 不是索引键那么 InnoDB 将完成表锁，并发将无从谈起；

数据库优化的思路

SQL 优化

在我们书写 SQL 语句的时候，其实书写的顺序、策略会影响到 SQL 的性能，虽然实现的功能是一样的，但是它们的性能会有些许差别。因此，下面就讲解在书写 SQL 的时候，怎么写比较好。

1. 选择最有效率的表名顺序。

   
   

   数据库的解析器按照从右到左的顺序处理 FROM 子句中的表名，FROM 子句中写在最后的表将被最先处理。

   
   

   在 FROM 子句中包含多个表的情况下：

   
   

   如果三个表是完全无关系的话，将记录和列名最少的表，写在最后，然后依次类推

   
   

   也就是说：选择记录条数最少的表放在最后。

   
   

   如果有 3 个以上的表连接查询：

   
   

   如果三个表是有关系的话，将引用最多的表，放在最后，然后依次类推。

   
   

   也就是说：被其他表所引用的表放在最后

   
   

   例如：查询员工的编号，姓名，工资，工资等级，部门名 emp 表被引用得最多，记录数也是最多，因此放在 form 字句的最后面

select emp.empno,emp.ename,emp.sal,salgrade.grade,dept.dname from salgrade,dept,emp where (emp.deptno = dept.deptno) and (emp.sal between salgrade.losal and salgrade.hisal)

1. WHERE 子句中的连接顺序

数据库采用自右而左的顺序解析 WHERE 子句，根据这个原理，表之间的连接必须写在其他 WHERE 条件之左，那些可以过滤掉最大数量记录的条件必须写在 WHERE 子句的之右。

emp.sal 可以过滤多条记录，写在 WHERE 字句的最右边

select emp.empno,emp.ename,emp.sal,dept.dname from dept,emp where (emp.deptno = dept.deptno) and (emp.sal > 1500)

1. SELECT 子句中避免使用*号

“*”号是可以获取表中全部的字段数据的。但是它要通过查询数据字典完成的，这意味着将耗费更多的时间，使用*号写出来的 SQL 语句也不够直观。

1. 用 TRUNCATE 替代 DELETE

这里仅仅是：删除表的全部记录，除了表结构才这样做。DELETE 是一条一条记录的删除，而 Truncate 是将整个表删除，保留表结构，这样比 DELETE 快。

1. 多使用内部函数提高 SQL 效率

例如使用 mysql 的 concat()函数会比使用||来进行拼接快，因为 concat()函数已经被 mysql 优化过了。

1. 使用表或列的别名

如果表或列的名称太长了，使用一些简短的别名也能稍微提高一些 SQL 的性能。毕竟要扫描的字符长度就变少了。

1. 多使用 commit

comiit 会释放回滚。

1. 善用索引

索引就是为了提高我们的查询数据的，当表的记录量非常大的时候，我们就可以使用索引了。

1. SQL 写大写

我们在编写 SQL 的时候，官方推荐的是使用大写来写关键字，因为 Oracle 服务器总是先将小写字母转成大写后，才执行。

1. 避免在索引列上使用 NOT

因为 Oracle 服务器遇到 NOT 后，他就会停止目前的工作，转而执行全表扫描

1. 避免在索引列上使用计算

WHERE 子句中，如果索引列是函数的一部分，优化器将不使用索引而使用全表扫描，这样会变得变慢。

1. 用 >= 替代 >
   

## 低效：SELECT * FROM EMP WHERE DEPTNO > 3   ## 首先定位到DEPTNO=3的记录并且扫描到第一个DEPT大于3的记录
## 高效：SELECT * FROM EMP WHERE DEPTNO >= 4  ## 直接跳到第一个DEPT等于4的记录

1. 用 IN 替代 OR

select * from emp where sal = 1500 or sal = 3000 or sal = 800;select * from emp where sal in (1500,3000,800);

1. 总是使用索引的第一个列

如果索引是建立在多个列上，只有在它的第一个列被 WHERE 子句引用时，优化器才会选择使用该索引。 当只引用索引的第二个列时，不引用索引的第一个列时，优化器使用了全表扫描而忽略了索引

create index emp_sal_job_idex on emp(sal,job);## ----------------------------------select * from emp where job != 'SALES';    ## 上边就不使用索引了。

数据库结构优化

1. 范式优化：比如消除冗余（节省空间。。）

2. 反范式优化：比如适当加冗余等（减少 join）

3. 拆分表：垂直拆分和水平拆分

服务器硬件优化

这个么多花钱咯！