我之前从未使用过外国钥匙。我总是将id放在一个关键列上,但它不一定是外键。所以它就像一个外键,但它不是。
所以,如果我有以下2个表
CREATE TABLE `accounts` (
`account_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(60) NOT NULL,
`owner_id` int(11) unsigned NOT NULL,
PRIMARY KEY (`account_id`),
KEY `owner_id` (`owner_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
CREATE TABLE `users` (
`user_id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(60) NOT NULL
PRIMARY KEY (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
列account.owner_id链接到users.user_id但未设置外键关系。
所以我可以做这样的事情
SELECT
a.name AS account_name,
u.name AS user_name FROM
accounts AS a INNER JOIN users AS u ON u.user_id = a.owner_id
因此,在了解了FOREIGN KEYS是什么以及他们做了什么后,我创建了一个外键,就像这样。
ALTER TABLE accounts
ADD CONSTRAINT fk_owner_id FOREIGN KEY(owner_id)
REFERENCES users(user_id) ON DELETE NO ACTION ON UPDATE CASCADE;
但是,我注意到性能发生了变化,因为系统运行速度很慢。我不确定添加FOREIGN KEYs是否会重复使用性能?或者在向表中添加外键时是否会降低性能? 请注意,我的数据库中有很多表和列。所以我做了很多INNER / LEFT / RIGHT JOINS以及我将它们识别为FOREIGN KEYS的所有列都被编入索引。注意我没有向这些列添加任何索引,因为在将FOREIGN密钥添加到我的数据库之前它们已经存在。
我的问题,FOREIGN KEY会降低UPDATE / INSERT / DELETE / SELECT的性能吗? 当我们指定ON DELETE NO ACTION ON UPDATE NO ACTION时,还有添加FOREIGN KEY约束的好处吗?
由于
答案 0 :(得分:6)
外键约束意味着对FK列的任何插入都必须检查引用的用户列中是否存在该值。可能会有一些开销,但它是一个定义的索引查找(可能是PK查找)所以成本不应该很高。
在子表的某些更新期间,外键还会在父表上创建共享锁。这可能妨碍对该表的并发更新,并使系统看起来性能较慢。见http://www.mysqlperformanceblog.com/2006/12/12/innodb-locking-and-foreign-keys/
如果没有索引,外键还隐式在FK列上创建了一个索引。每次插入,更新,删除都必须在更改时修改表的所有索引,因此会产生一些开销。出于这个原因,有人说索引“伤害”插入,更新,删除的性能。但事情并非如此简单 - 在WHERE子句中支持条件的索引可以通过更有效地查找受影响的行来使更新或删除运行更快。
重新评论:
是的,对子表的任何更新都会在子表的已修改行上创建独占锁。你可能期待这个。但此操作还会在clients
中引用的行上创建共享锁。任意数量的会话可以在同一行上独立创建共享锁(因此共享名称)。但是,独占锁需要没有任何类型的锁。因此,如果clients
中的行中经常存在未完成的共享锁,则clients
中对该行的直接更新无法获得所需的独占锁定。
这些共享锁的目的基本上是这样,当有人更新依赖它的行时,clients
中的行不会被删除或修改。换句话说,“不要删除我的父母。”但是,根据更新的频率和事务的持续时间,可能会很难对父行执行更新。
缓解这种情况的一种方法是尝试通过及时完成事务的工作,然后提交来使锁更长时间生效。