MySQL 中优化 SQL 语句查询常用的方法

Mysql IT敢客 4个月前 (08-15) 1598次浏览 已收录 0个评论 扫描二维码

以下是从网络搜索整理的 MySQL 中优化 SQL 语句查询常用的方法汇总。

MySQL 中优化 SQL 语句查询常用的方法

1、选取最适用的字段属性
MySQL 可以很好的支持大数据量的存取,但是一般说来,数据库中的表越小,在它上面执行的查询也就会越快。因此,在创建表的时候,为了获得更好的性能,我们可以将表中字段的宽度设得尽可能小。例如,在定义邮政编码这个字段时,如果将其设置为 CHAR(255),显然给数据库增加了不必要的空间,甚至使用 VARCHAR 这种类型也是多余的,因为 CHAR(6)就可以很好的完成任务了。同样的,如果可以的话,我们应该使用 MEDIUMINT 而不是 BIGIN 来定义整型字段。
另外一个提高效率的方法是在可能的情况下,应该尽量把字段设置为 NOT NULL,这样在将来执行查询的时候,数据库不用去比较 NULL 值。
对于某些文本字段,例如“省份”或者“性别”,我们可以将它们定义为 ENUM 类型。因为在 MySQL 中,ENUM 类型被当作数值型数据来处理,而数值型数据被处理起来的速度要比文本类型快得多。这样,我们又可以提高数据库的性能。

2、使用连接(JOIN)来代替子查询(Sub-Queries)
MySQL 从 4.1 开始支持 SQL 的子查询。这个技术可以使用 SELECT 语句来创建一个单列的查询结果,然后把这个结果作为过滤条件用在另一个查询中。例如,我们要将客户基本信息表中没有任何订单的客户删除掉,就可以利用子查询先从销售信息表中将所有发出订单的客户 ID 取出来,然后将结果传递给主查询,如下所示:

DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )

使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的 SQL 操作,同时也可以避免事务或者表锁死,并且写起来也很容易。但是,有些情况下,子查询可以被更有效率的连接(JOIN).. 替代。

例如,假设我们要将所有没有订单记录的用户取出来,可以用下面这个查询完成:

SELECT * FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )

如果使用连接(JOIN).. 来完成这个查询工作,速度将会快很多。尤其是当 salesinfo 表中对 CustomerID 建有索引的话,性能将会更好,查询如下:

SELECT * FROM customerinfo LEFT JOIN salesinfoON customerinfo.CustomerID=salesinfo. CustomerID WHERE salesinfo.CustomerID IS NULL

连接(JOIN).. 之所以更有效率一些,是因为 MySQL 不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。

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

下面的例子就演示了一个使用 UNION 的查询。

SELECT Name, Phone FROM client UNION SELECT Name, BirthDate FROM author UNION SELECT Name, Supplier FROM product

4、事务
尽管我们可以使用子查询(Sub-Queries)、连接(JOIN)和联合(UNION)来创建各种各样的查询,但不是所有的数据库操作都可以只用一条或少数几条 SQL 语句就可以完成的。更多的时候是需要用到一系列的语句来完成某种工作。

但是在这种情况下,当这个语句块中的某一条语句运行出错的时候,整个语句块的操作就会变得不确定起来。设想一下,要把某个数据同时插入两个相关联的表中,可能会出现这样的情况:第一个表中成功更新后,数据库突然出现意外状况,造成第二个表中的操作没有完成,这样,就会造成数据的不完整,甚至会破坏数据库中的数据。

要避免这种情况,就应该使用事务,它的作用是:要么语句块中每条语句都操作成功,要么都失败。

换句话说,就是可以保持数据库中数据的一致性和完整性。事物以 BEGIN 关键字开始,COMMIT 关键字结束。在这之间的一条 SQL 操作失败,那么,ROLLBACK 命令就可以把数据库恢复到 BEGIN 开始之前的状态。

BEGIN;
INSERT INTO salesinfo SET CustomerID=14;
UPDATE inventory SET Quantity=11
WHERE item='book';
COMMIT;

事务的另一个重要作用是当多个用户同时使用相同的数据源时,它可以利用锁定数据库的方法来为用户提供一种安全的访问方式,这样可以保证用户的操作不被其它的用户所干扰。

5、锁定表
尽管事务是维护数据库完整性的一个非常好的方法,但却因为它的独占性,有时会影响数据库的性能,尤其是在很大的应用系统中。由于在事务执行的过程中,数据库将会被锁定,因此其它的用户请求只能暂时等待直到该事务结束。如果一个数据库系统只有少数几个用户
来使用,事务造成的影响不会成为一个太大的问题;但假设有成千上万的用户同时访问一个数据库系统,例如访问一个电子商务网站,就会产生比较严重的响应延迟。
其实,有些情况下我们可以通过锁定表的方法来获得更好的性能。下面的例子就用锁定表的方法来完成前面一个例子中事务的功能。

LOCK TABLE inventory WRITE
SELECT Quantity FROM inventory
WHEREItem='book';
...
UPDATE inventory SET Quantity=11
WHEREItem='book';
UNLOCK TABLES

这里,我们用一个 SELECT 语句取出初始数据,通过一些计算,用 UPDATE 语句将新值更新到表中。包含有 WRITE 关键字的 LOCK TABLE 语句可以保证在 UNLOCK TABLES 命令被执行之前,不会有其它的访问来对 inventory 进行插入、更新或者删除的操作。

6、使用外键
锁定表的方法可以维护数据的完整性,但是它却不能保证数据的关联性。这个时候我们就可以使用外键。例如,外键可以保证每一条销售记录都指向某一个存在的客户。在这里,外键可以把 customerinfo 表中的 CustomerID 映射到 salesinfo 表中 CustomerID,任何一条没有合法 CustomerID 的记录都不会被更新或插入到 salesinfo 中。

CREATE TABLE customerinfo
(
CustomerID INT NOT NULL ,
PRIMARY KEY ( CustomerID )
) TYPE = INNODB;
CREATE TABLE salesinfo
(
SalesID INT NOT NULL,
CustomerID INT NOT NULL,
PRIMARY KEY(CustomerID, SalesID),
FOREIGN KEY (CustomerID) REFERENCES customerinfo
(CustomerID) ON DELETECASCADE
) TYPE = INNODB;

注意例子中的参数“ON DELETE CASCADE”。该参数保证当 customerinfo 表中的一条客户记录被删除的时候,salesinfo 表中所有与该客户相关的记录也会被自动删除。如果要在 MySQL 中使用外键,一定要记住在创建表的时候将表的类型定义为事务安全表 InnoDB 类型。该类型不是 MySQL 表的默认类型。定义的方法是在 CREATE TABLE 语句中加上 TYPE=INNODB。如例中所示。

7、使用索引
索引是提高数据库性能的常用方法,它可以令数据库服务器以比没有索引快得多的速度检索特定的行,尤其是在查询语句当中包含有 MAX(), MIN()和 ORDERBY 这些命令的时候,性能提高更为明显。

那该对哪些字段建立索引呢?一般说来,索引应建立在那些将用于 JOIN, WHERE 判断和 ORDER BY 排序的字段上。尽量不要对数据库中某个含有大量重复的值的字段建立索引。对于一个 ENUM 类型的字段来说,出现大量重复值是很有可能的情况,例如 customerinfo 中的“province”.. 字段,在这样的字段上建立索引将不会有什么帮助;相反,还有可能降低数据库的性能。

我们在创建表的时候可以同时创建合适的索引,也可以使用 ALTER TABLE 或 CREATE INDEX 在以后创建索引。此外,MySQL 从版本 3.23.23 开始支持全文索引和搜索。全文索引在 MySQL 中是一个 FULLTEXT 类型索引,但仅能用于 MyISAM 类型的表。

对于一个大的数据库,将数据装载到一个没有 FULLTEXT 索引的表中,然后再使用 ALTER TABLE 或 CREATE INDEX 创建索引,将是非常快的。但如果将数据装载到一个已经有 FULLTEXT 索引的表中,执行过程将会非常慢。

8、优化的查询语句
绝大多数情况下,使用索引可以提高查询的速度,但如果 SQL 语句使用不恰当的话,索引将无法发挥它应有的作用。下面是应该注意的几个方面。首先,最好是在相同类型的字段间进行比较的操作。

在 MySQL 3.23 版之前,这甚至是一个必须的条件。例如不能将一个建有索引的 INT 字段和 BIGINT 字段进行比较;但是作为特殊的情况,在 CHAR 类型的字段和 VARCHAR 类型字段的字段大小相同的时候,可以将它们进行比较。其次,在建有索引的字段上尽量不要使用函数进行操作。
例如,在一个 DATE 类型的字段上使用 YEAE()函数时,将会使索引不能发挥应有的作用。所以,下面的两个查询虽然返回的结果一样,但后者要比前者快得多。

SELECT * FROM order WHERE YEAR(OrderDate)<2017;
SELECT * FROM order WHERE OrderDate<"2017-01-01";

同样的情形也会发生在对数值型字段进行计算的时候:

SELECT * FROM inventory WHERE Amount/7<24;
SELECT * FROM inventory WHERE Amount<24*7;

上面的两个查询也是返回相同的结果,但后面的查询将比前面的一个快很多。第三,在搜索字符型字段时,我们有时会使用 LIKE 关键字和通配符,这种做法虽然简单,

但却也是以牺牲系统性能为代价的。例如下面的查询将会比较表中的每一条记录。

SELECT * FROM books
WHERE name like "MySQL%"

但是如果换用下面的查询,返回的结果一样,但速度就要快上很多:

SELECT * FROM books
WHERE name>="MySQL"and name<"MySQM"

9、对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。 

10、应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。 

11、应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如: 
select id from t where num is null 
可以在 num 上设置默认值 0,确保表中 num 列没有 null 值,然后这样查询: 
select id from t where num=0 

12、应尽量避免在 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 

13、下面的查询也将导致全表扫描: 
select id from t where name like ‘%abc%’ 
若要提高效率,可以考虑全文检索。 

14、in 和 not in 也要慎用,否则会导致全表扫描,如: 
select id from t where num in(1,2,3) 
对于连续的数值,能用 between 就不要用 in 了: 
select id from t where num between 1 and 3 

15、如果在 where 子句中使用参数,也会导致全表扫描。因为 SQL 只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。如下面语句将进行全表扫描: 
select id from t where num=@num 
可以改为强制查询使用索引: 
select id from t with(index(索引名)) where num=@num 

16、应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如: 
select id from t where num/2=100 
应改为: 
select id from t where num=100*2 

17、应尽量避免在 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’ 

18、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。 

19、在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使用,并且应尽可能的让字段顺序与索引顺序相一致。 

21、不要写一些没有意义的查询,如需要生成一个空表结构: 
select col1,col2 into #t from t where 1=0 
这类代码不会返回任何结果集,但是会消耗系统资源的,应改成这样: 
create table #t(…) 

22、很多时候用 exists 代替 in 是一个好的选择: 
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) 

23、并不是所有索引对查询都有效,SQL 是根据表中数据来进行查询优化的,当索引列有大量数据重复时,SQL 查询可能不会去利用索引,如一表中有字段 sex,male、female 几乎各一半,那么即使在 sex 上建了索引也对查询效率起不了作用。 

24、索引并不是越多越好,索引固然可以提高相应的 select 的效率,但同时也降低了 insert 及 update 的效率,因为 insert 或 update 时有可能会重建索引,所以怎样建索引需要慎重考虑,视具体情况而定。一个表的索引数最好不要超过 6 个,若太多则应考虑一些不常使用到的列上建的索引是否有必要。 

25、应尽可能的避免更新 clustered 索引数据列,因为 clustered 索引数据列的顺序就是表记录的物理存储顺序,一旦该列值改变将导致整个表记录的顺序的调整,会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列,那么需要考虑是否应将该索引建为 clustered 索引。 

26、尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。 

27、尽可能的使用 varchar/nvarchar 代替 char/nchar ,因为首先变长字段存储空间小,可以节省存储空间,其次对于查询来说,在一个相对较小的字段内搜索效率显然要高些。 

28、任何地方都不要使用 select * from t ,用具体的字段列表代替“*”,不要返回用不到的任何字段。 

29、尽量使用表变量来代替临时表。如果表变量包含大量数据,请注意索引非常有限(只有主键索引)。 

30、避免频繁创建和删除临时表,以减少系统表资源的消耗。 

31、临时表并不是不可使用,适当地使用它们可以使某些例程更有效,例如,当需要重复引用大型表或常用表中的某个数据集时。但是,对于一次性事件,最好使用导出表。 

32、在新建临时表时,如果一次性插入数据量很大,那么可以使用 select into 代替 create table,避免造成大量 log ,以提高速度;如果数据量不大,为了缓和系统表的资源,应先 create table,然后 insert。 

33、如果使用到了临时表,在存储过程的最后务必将所有的临时表显式删除,先 truncate table ,然后 drop table ,这样可以避免系统表的较长时间锁定。 

34、尽量避免使用游标,因为游标的效率较差,如果游标操作的数据超过 1 万行,那么就应该考虑改写。 

35、使用基于游标的方法或临时表方法之前,应先寻找基于集的解决方案来解决问题,基于集的方法通常更有效。 

36、与临时表一样,游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法,尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许,基于游标的方法和基于集的方法都可以尝试一下,看哪一种方法的效果更好。 

37、在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ,在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。 

38、尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理。 

39、尽量避免大事务操作,提高系统并发能力。

40、应该注意避免在查询中让 MySQL 进行自动类型转换,因为转换过程也会使索引变得不起作用。

MySQL 服务器硬件和操作系统调节:

41、 拥有足够的物理内存来把整个 InnoDB 文件加载到内存中——在内存中访问文件时的速度要比在硬盘中访问时快的多。

42、 不惜一切代价避免使用 Swap 交换分区 – 交换时是从硬盘读取的,它的速度很慢。

43、 使用电池供电的 RAM(注:RAM 即随机存储器)。

44、使用高级的 RAID(注:Redundant Arrays of Inexpensive Disks,即磁盘阵列) – 最好是 RAID10 或更高。

45、避免 RAID5(注:一种存储性能、数据安全和存储成本兼顾的存储解决方案) – 确保数据库完整性的校验是要付出代价的。

46、 将操作系统和数据分区分开,不仅仅是逻辑上,还包括物理上– 操作系统的读写操作会影响数据库的性能。

47、把 MySQL 临时空间和复制日志与数据放到不同的分区– 当数据库后台从磁盘进行读写操作时会影响数据库的性能。

48、 更多的磁盘空间等于更快的速度。

49、更好更快的磁盘。

50、使用 SAS(注: Serial Attached SCSI,即串行连接 SCSI)代替 SATA(注:SATA,即串口硬盘)。

51、 较小的硬盘 比 较大的硬盘快,尤其是在 RAID 配置的情况下。

52、 使用电池支持的高速缓存 RAID 控制器。

53、避免使用软件磁盘阵列。

54、考虑为数据分区使用固态 IO 卡 (不是磁盘驱动器) – 这些卡能够为几乎任何数量的数据支持 2GB/s 的写入速度。

55、在 Linux 中设置 swappiness 的值为 0 – 在数据库服务器中没有理由缓存文件,这是一个服务器或台式机的优势。

56、如果可以的话,使用 noatime 和 nodirtime 挂载文件系统 – 没有理由更新访问数据库文件的修改时间。

57、使用 XFS 文件系统 – 一种比 ext3 更快、更小的文件系统,并且有许多日志选项, 而且 ext3 已被证实与 MySQL 有双缓冲问题。

58、调整 XFS 文件系统日志和缓冲变量 – 为了最高性能标准。

59、在 Linux 系统中, 使用 NOOP 或者 DEADLINE IO 定时调度程序 – 同 NOOP 和 DEADLINE 定时调度程序相比,这个 CFQ 和 ANTICIPATORY 定时调度程序 显得非常慢。

60、使用 64 位的操作系统 – 对于 MySQL,会有更大的内存支持和使用。

61、删除服务器上未使用的安装包和守护进程– 更少的资源占用。

62、 把使用 MySQL 的 host 和你的 MySQL host 放到一个 hosts 文件中 – 没有 DNS 查找。

63、切勿强制杀死一个 MySQL 进程 – 你会损坏数据库和正在运行备份的程序。

64、把服务器贡献给 MySQL – 后台进程和其他服务能够缩短数据库占用 CPU 的时间。

MySQL 配置:

65、当写入时,使用 innodb_flush_method=O_DIRECT 来避免双缓冲。

66、避免使用 O_DIRECT 和 EXT3 文件系统 – 你将序列化所有要写入的。

67、 分配足够的 innodb_buffer_pool_size 来加载整个 InnoDB 文件到内存中– 少从磁盘中读取。

68、 不要将 innodb_log_file_size 参数设置太大, 这样可以更快同时有更多的磁盘空间 – 丢掉多的日志通常是好的,在数据库崩溃后可以降低恢复数据库的时间。

69、不要混用 innodb_thread_concurrency 和 thread_concurrency 参数– 这 2 个值是不兼容的。

70、 分配一个极小的数量给 max_connections 参数 – 太多的连接会用尽 RAM 并锁定 MySQL 服务。

71、保持 thread_cache 在一个相对较高的数字,大约 16 – 防止打开连接时缓慢。

72、使用 skip-name-resolve 参数 – 去掉 DNS 查找。

73、如果你的查询都是重复的,并且数据不常常发生变化,那么可以使用查询缓存。但是如果你的数据经常发生变化,那么使用查询缓存会让你感到失望。\

74、增大 temp_table_size 值,以防止写入磁盘

75、增大 max_heap_table_size 值,以防止写入磁盘

76、不要把 sort_buffer_size 值设置的太高,否则的话你的内存将会很快耗尽

77、根据 key_read_requests 和 key_reads 值来决定 key_buffer 的大小,一般情况下 key_read_requests 应该比 key_reads 值高,否则你不能高效的使用 key_buffer

78、将 innodb_flush_log_at_trx_commit 设置为 0 将会提高性能,但是如果你要保持默认值(1)的话,那么你就要确保数据的完整性,同时你也要确保复制不会滞后。

79、你要有一个测试环境,来测试你的配置,并且在不影响正常生产的情况下,可以常常进行重启。

MySQL 模式优化:

80、保持你的数据库整理性。

81、 旧数据归档 – 删除多余的行返回或搜索查询。

82、将您的数据加上索引.

83、不要过度使用索引,比较与查询.

84、压缩文字和 BLOB 数据类型 – 以节省空间和减少磁盘读取次数.

85、UTF 8 和 UTF16 都低于 latin1 执行效率.

86、 有节制地使用触发器.

87、冗余数据保持到最低限度 – 不重复不必要的数据.

88、使用链接表,而不是扩展行.

89、注意数据类型,在您的真实数据中,尽可能使用最小的一个.

90、如果其他数据经常被用于查询时,而 BLOB / TEXT 数据不是,就把 BLOB / TEXT 数据从其他数据分离出来.

91、检查和经常优化表.

92、经常重写 InnoDB 表优化.

93、有时,当添加列时删除索引,然后在添加回来索引,这样就会更快.

94、针对不同的需求,使用不同的存储引擎.

95、 使用归档存储引擎日志表或审计表-这是更有效地写道.

96、会话数据存储在缓存(memcache)的而不是 MySQL 中 – 缓存允许自动自动填值的,并阻止您创建难以读取和写入到 MySQL 的时空数据.

97、存储可变长度的字符串时使用 VARCHAR 而不是 CHAR – 节省空间,因为固定长度的 CHAR,而 VARCHAR 长度不固定(UTF8 不受此影响).

98、 逐步进行模式的变化 – 一个小的变化,可以有巨大的影响.

99、在开发环境中测试所有模式,反映生产变化.

100、不要随意更改你的配置文件中的值,它可以产生灾难性的影响.

101、有时候,在 MySQL 的 configs 少即是多.

102、有疑问时使用一个通用的 MySQL 配置文件.

查询优化:

103、使用慢查询日志去发现慢查询。

104、 使用执行计划去判断查询是否正常运行。

105、总是去测试你的查询看看是否他们运行在最佳状态下 –久而久之性能总会变化。

106、 避免在整个表上使用 count(*),它可能锁住整张表。

107、使查询保持一致以便后续相似的查询可以使用查询缓存。

108、在适当的情形下使用 GROUP BY 而不是 DISTINCT。

109、 在 WHERE, GROUP BY 和 ORDER BY 子句中使用有索引的列。

110、保持索引简单,不在多个索引中包含同一个列。

111、有时候 MySQL 会使用错误的索引,对于这种情况使用 USE INDEX。

112、检查使用 SQL_MODE=STRICT 的问题。

113、 对于记录数小于 5 的索引字段,在 UNION 的时候使用 LIMIT 不是是用 OR.

114、为了 避免在更新前 SELECT,使用 INSERT ON DUPLICATE KEY 或者 INSERT IGNORE ,不要用 UPDATE 去实现。

115、 不要使用 MAX,使用索引字段和 ORDER BY 子句。

116、 避免使用 ORDER BY RAND().

117、LIMIT M,N 实际上可以减缓查询在某些情况下,有节制地使用。

118、在 WHERE 子句中使用 UNION 代替子查询。

119、对于 UPDATES(更新),使用 SHARE MODE(共享模式),以防止独占锁。

120、在重新启动的 MySQL,记得来温暖你的数据库,以确保您的数据在内存和查询速度快。

121、使用 DROP TABLE,CREATE TABLE DELETE FROM 从表中删除所有数据。

122、最小化的数据在查询你需要的数据,使用*消耗大量的时间。

123、考虑持久连接,而不是多个连接,以减少开销。

124、基准查询,包括使用服务器上的负载,有时一个简单的查询可以影响其他查询。

125、当负载增加您的服务器上,使用 SHOW PROCESSLIST 查看慢的和有问题的查询。

126、在开发环境中产生的镜像数据中 测试的所有可疑的查询。

MySQL 备份过程:

127、从二级复制服务器上进行备份。

128、在进行备份期间停止复制,以避免在数据依赖和外键约束上出现不一致。

129、彻底停止 MySQL,从数据库文件进行备份。

130、 如果使用 MySQL dump 进行备份,请同时备份二进制日志文件– 确保复制没有中断。

131、不要信任 LVM 快照 – 这很可能产生数据不一致,将来会给你带来麻烦。

132、为了更容易进行单表恢复,以表为单位导出数据 – 如果数据是与其他表隔离的。

133、当使用 mysqldump 时请使用 –opt。

134、在备份之前检查和优化表。

135、为了更快的进行导入,在导入时临时禁用外键约束。

136、为了更快的进行导入,在导入时临时禁用唯一性检测。

137、在每一次备份后计算数据库,表以及索引的尺寸,以便更够监控数据尺寸的增长。

138、通过自动调度脚本监控复制实例的错误和延迟。

139、定期执行备份。

140、定期测试你的备份。


IT 敢客 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明原文链接:MySQL 中优化 SQL 语句查询常用的方法
喜欢 (7)
[313176056@qq.com]
分享 (0)
IT敢客
关于作者:
“我所做的一切都是为了方便我的生活~~~“
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址