数据库就像一个超大仓库,优化逻辑结构就是让“货物”存取更快!
核心角色:
问题:为什么查询有时特别慢?可能是“货架”没选对!
步骤:
SELECT name, value FROM v$parameter WHERE name = 'db_block_size';
真实场景:
双11秒杀时,热门商品总被抢购导致数据库卡顿?
解决:把商品分散到多个货架(哈希分区):
CREATE TABLE hot_items (
item_id NUMBER,
data VARCHAR2(1000)
) PARTITION BY HASH(item_id) PARTITIONS 4; -- 分成4个区
问题:删除数据后,空间为什么不释放?
操作:整理货架区,释放僵尸空间!
-- 整理表货架区
ALTER TABLE sales MOVE TABLESPACE users;
-- 重建索引(索引就像货架目录)
ALTER INDEX sales_pk REBUILD;
口诀:
货架区扩展要像拼乐高:
一次多拼几块(NEXT
参数调大)
避免频繁拼装(减少扩展次数)
场景:已知货物位置时,直接按快递单号取货最快!
-- 直接通过ROWID查数据(比扫码快10倍!)
SELECT * FROM employees WHERE ROWID = 'AAASh9AABAAAACXAAA';
注意:ROWID就像快递单号,表重建后会失效!
高级用法:把历史数据扔进“慢速仓库”,节省高速仓库空间!
-- 创建历史数据表空间(放在HDD硬盘)
CREATE TABLESPACE history_ts
DATAFILE '/slow_disk/history.dbf' SIZE 10G;
-- 迁移旧数据
ALTER TABLE orders MOVE PARTITION orders_2020 TABLESPACE history_ts;
现象:更新数据后查询变慢
解决:
SELECT table_name, num_rows, chain_cnt FROM dba_tables WHERE chain_cnt > 0;
ALTER TABLE ... MOVE
重组表案例:某商品每秒被访问10万次,导致CPU飙升
优化:
当发现DB_FILE_MULTIBLOCK_READ_COUNT
值过高时,应该优先调整哪个参数?
答案:块大小(db_block_size
),因为大块能一次性读取更多数据。
哪种场景适合直接使用ROWID查询?
答案:已知精确位置且数据量小的场景,比如通过日志定位单条数据。
块太大容易浪费,太小了总在翻找
分区就像分货架,冷热分开效率高
快递单号虽方便,表格重建就失效
-- 实验:查看你的用户表空间使用情况
SELECT tablespace_name,
ROUND(SUM(bytes)/1024/1024) "已用空间(MB)",
ROUND(SUM(maxbytes)/1024/1024) "最大空间(MB)"
FROM dba_data_files
WHERE tablespace_name = 'USERS'
GROUP BY tablespace_name;
下期预告:《SQL优化之表设计》
互动话题:你在学习SQL时遇到过哪些坑?欢迎评论区留言讨论!
️温馨提示:我是[随缘而动,随遇而安], 一个喜欢用生活案例讲技术的开发者。如果觉得有帮助,点赞关注不迷路