
1、建筑表
CREATE
TABLE
buildings
(
building_no
INT
PRIMARY
KEY
AUTO_INCREMENT,
building_name
VARCHAR(255)
NOT
NULL,
address
VARCHAR(255)
NOT
NULL
)
2、房间表
CREATE
TABLE
rooms
(
room_no
INT
PRIMARY
KEY
AUTO_INCREMENT,
room_name
VARCHAR(255)
NOT
NULL,
building_no
INT
NOT
NULL,
FOREIGN
KEY
(building_no)
REFERENCES
buildings
(building_no)
ON
DELETE
CASCADE
//这里指定了级联删除
)
3、执行删除会把building_no=2的room记录都删除了
DELETE
FROM
buildings
WHERE
building_no
=
2
您好,我觉得删除 *** 作巨慢的原因可能有以下几个:1、删除的条件判断占用了很久,比如删除的条件用不到任何索引且不是主键。2、删除的表中建立了索引而且数据量比较大,每次删除都要更新很多索引信息。3、可能单纯的删除的数据量比较大。4、可能数据库同时在执行其他消耗很大的 *** 作。Mysql主从同步延迟发生 现象: pos一直保持不变,并且behind一直在增加, 备库执行: SQL thread State列状态如下: 代表 线程已经从中继日志读取一个事件,可以对事件进行处理了。 查看binlog: 查看表结构发现没有主键和索引。 延迟发生原因: 首先mysql主从是基于行的复制。 举例解释下什么是基于行的复制,假设主库执行以下sql删除了表A中的100条数据: 这时mysql会把这个SQL按照每条记录,拆分成100条delete SQL在备库上执行,mysql这么做的目的也是最大程度的保证同步数据的可靠性。 但是可靠性的提升伴随而来的便是日志量的增多,同步过程会占用大量带宽。 其次,该表即无主键,也没有索引。 假设还是以上对A表的删除 *** 作,拆成的100条delete SQL传递并且在备库执行,因为表即无主键,也没有索引,所以每执行一次都要做全表扫描才能定位到要删除的那一条数据,可想而知同步效率会低很多。 解决方案: 1 表设计时就要有主键; 2 如果延迟已经发生,并且表不是特别大的情况下,在备库上为该表创建索引或是主键。欢迎分享,转载请注明来源:内存溢出
微信扫一扫
支付宝扫一扫
评论列表(0条)