mysql数据字典应用场景_为什么你必须掌握数据字典？

数据字典，号称是数据中的数据。

在我看来，数据字典就是一个大管家。小到一根针，大到一个保姆，管家不仅要记录得分毫不差，还要随时快捷地找到他想要的东西或者人。

一个数据库应用开始的时候，需求还不旺盛，很多功能还不到时候开发，所以可能有2，30张表。可以是人物表，地点表，时间表，活动表等等。此时，我们记得住这些表，某个数据在哪里，信手捏来。

但，假设业务开展的特别好，产品特别给力，运营也很奥里给，业务活动噌噌往上涨，各种花哨功能也上来了，比如618，双十一，团购等等，各种表是加了又加，一时间猛增到了大几百张表，如果说表名靠命名格式，还能猜得出来，那么字段名是肯定没法猜准了。

那你有没有想过，数据库是怎么记住这些表的呢？对，就是靠数据字典。

有了它，我们记不住精确的表名，没关系，一条语句就能搞定：

SELECT NAME

FROM sys.tables

SELECT *

FROM ALL_TABLES

怎么查某张表的字段名呢？

SELECT NAME

FROM sys.columns

SELECT *

FROM ALL_TAB_COULUMNS

有同学就会问，知道这些有啥好处呢，嗯，好处多着呢，慢慢来看真香部分：

更新部分字段

比如很多信息系统，为了各种原因，选择只传输部分字段来做更新。如果不知如何利用字典表，那么我猜，开发很可能会自己维护一张字段表，逐一去对比字段，然后更新。

table A( a int, b int, c int)

前端传进来的参数是个二维表，类似下面这样：

@updateColumns(Key,Value)

在这份表结构中，可以传多个字段的更新值，也可以只传一个。

这个时候，通常我们会维护一张字段表，类似这样：

table:columns_mapping

(TableName,TableColumn)

--------- ------------

A a

A b

A c

这样，每次通过参数@updateColumns结构传进来的字段，就能通过Join,准确知道。比如 @updateColumns的参数是这样的值：

Key Value

---- -----

a 10001

c 20001

这样，程序就能知道，只要更新 a 和 c 字段的值即可。

上面这个方法呢，有个不高级的地方，我们每次增加一个字段，都要去这个表里，维护一下，而且对这张表也 要做严格的安全限制。

因此，使用字典表，sys.columns 就一劳永逸了。数据字典表是绝对安全的，而且强数据一致性。

SELECT col.name AS ColumnName

FROM sys.columns col

INNER JOIN sys.tables tab

on col.object_id = tab.object_id

就能抓到所有指定表的字段名，不用人工维护，还安全。

查看统计值

经常碰到开发通过 count(*) 去统计一张表的记录数。这种做法，最大缺点就是费时，还能容易锁表，造成应用系统的堵塞和崩溃。

幸好数据字典帮我们做好统计值。每张表有多少记录，每个表被多少存储过程应用等等。

针对上面的案例，我们只要查下字典表，就能秒出结论：

SELECT *

FROM sys.partitions

当然，这种解决方法也有缺陷，在一个正常运行的系统中，不会即时更新表的统计值，那样造成压力更大。往往在窗口维护期间，一些费时的统计值更新才会由维护计划去执行。

数据字典，是资深开发的倚天剑，轻量但高效，推荐你掌握！

--完--