mar*_*c_s 25
您没有指定您正在使用的数据库系统 - 这些类型的东西总是非常特定于供应商.
这是适用于SQL Server的我的专有技术:
首先,SQL Server中的索引在其索引条目中最多只能有900个字节.仅这一点就不可能有一个包含所有列的索引.
最重要的是:这样的指数毫无意义.你想要实现什么？
考虑一下:如果你有一个索引(LastName, FirstName, Street, City),那么该索引将无法用于加速查询
FirstName 单独CityStreet 该索引对搜索有用
(LastName), 要么 (LastName, FirstName), 要么 (LastName, FirstName, Street), 要么 (LastName, FirstName, Street, City) 但实际上没有别的 - 如果你只搜索Street或只是搜索,肯定不会City!
索引中列的顺序有很大不同,查询优化器不能只使用索引中间某处的任何列进行查找.
考虑一下你的电话簿:它的订单可能是LastName,FirstName,也许是Street.那么索引是否可以帮助您找到您所在城市的所有"Joe's"？所有人都住在"主街"？不 - 你可以先通过LastName查找 - 然后在这组数据中获得更具体的信息.只要有高于一切的指标并不利于加快搜索所有列在所有.
如果您希望能够搜索Street- 您需要添加一个单独的索引(Street)(可能还有另外一列或两个有意义).
如果您希望能够搜索Occupation或其他任何内容 - 您需要另一个特定的索引.
仅仅因为您的列存在于索引中并不意味着"将加速该列的所有搜索!
主要规则是:使用尽可能少的索引 - 对于系统来说,太多的索引甚至可能比没有索引更糟糕......建立你的系统,监控它的性能,找到那些成本最高的查询 - 然后优化这些,例如通过添加索引.
不要只是因为你可以盲目索引每一列 - 这是糟糕的系统性能的保证 - 任何索引也需要维护和维护,所以你拥有的索引越多,你的INSERT,UPDATE和DELETE操作就越多(获取)因为所有这些指数都需要更新.
| 归档时间： |
|
| 查看次数： |
9804 次 |
| 最近记录： |