收集了一些关于管理拥有巨大表的数据库的技巧 - 链接
我们需要了解一下,目前数据库目前存在哪些性能瓶颈,然后再对症下药。
- 大表
生产数据库通常由许多具有不同数据、大小和模式的表组成。最终有一个巨大的、无序的数据库表,远远大于你数据库中的任何其他表。一个常见的原因是锁,对表的定期维护往往需要锁,但对大表的锁可能会使你的应用瘫痪,或导致堵塞和许多令人头痛的问题。
一些做基本维护的技巧,比如添加列或索引,同时避免长期运行的锁。添加索引的问题,是在创建索引的过程中锁住表。如果你有一个庞大的表,这可能需要几个小时。
方案:使用 CREATE INDEX CONCURRENTLY
功能,将索引创建分成两部分,一部分是短暂的锁定,以创建索引立即开始跟踪变化,但尽量减少应用阻塞,然后是完全建立该索引,之后查询可以开始使用它。
// 添加索引的问题
CREATE INDEX ON customers (last_name)
// 解决方法
CREATE INDEX CONCURRENTLY ON customers (last_name)
- 添加列
在数据库的使用过程中,添加列是一个常见的请求,但是对于一个巨大的表来说,这可能是很棘手的,同样是由于锁的问题。添加列的问题:当你添加一个新的默认值为一个函数的列时,Postgres
需要重写表。对于大表,这可能需要几个小时。
方案:将操作拆分为多条基本语句,总效果一致,但控制锁的时间。
// 添加列
ALTER TABLE all_my_exes ADD COLUMN location text;
// 添加默认值
ALTER TABLE all_my_exes ALTER COLUMN location SET DEFAULT texas();
// 使用UPDATE来添加默认值
UPDATE all_my_exes SET location = DEFAULT;
- 添加约束条件
问题: 你想添加一个用于数据验证的检查约束。但是如果你使用直接的方法来添加约束,它将锁定表,同时验证表中的所有现有数据。另外,如果在验证的任何时候出现错误,它将回滚。
方案:告诉 Postgres
这个约束,但不要验证它。在第二步中进行验证。这将在第一步中进行短暂的锁定,确保所有新的/修改过的行都符合约束条件,然后在另一步骤中进行验证,以确认所有现有的数据都通过约束条件。
// 添加约束条件
ALTER TABLE favorite_bands ADD CONSTRAINT name_check CHECK (name = 'Led Zeppelin');
// 约束但不要强制执行它
ALTER TABLE favorite_bands ADD CONSTRAINT name_check CHECK (name = 'Led Zeppelin') NOT VALID;
// 然后在创建后验证它
ALTER TABLE favorite_bands VALIDATE CONSTRAINT name_check