我遵循的一些规则会产生最大的不同.
不要在你的查询,如使用每排功能if,case,coalesce等等.通过以您将需要的格式将数据放入数据库来解决这些问题,即使这涉及重复数据.
例如,如果您需要快速查找姓氏,请将它们存储在输入的表单中,并以小写形式存储,并索引小写形式.那你就不必担心像select * from tbl where lowercase(surname) = 'smith';
是的,我知道打破3NF,但你仍然可以通过明智地使用触发器或预先计算的列来保证数据的完整性.例如,表上的插入/更新触发器可以强制将lower_surname列设置为小写版本surname.
这会将转换成本转移到insert/update(不经常发生)并远离select(发生的情况相当多).您基本上可以分摊转换成本.
确保对子where句中使用的每个列都编制索引.不一定是自己的,但至少作为复合键的主要部分.
始终以3NF开始,只有在遇到性能问题时才会恢复(在生产中).3NF通常是最容易处理的,只有在绝对必要时才能进行恢复.
生产中的配置文件(或其他地方,只要您有生产数据和模式).除非表中的数据永远不会发生变化(非常罕见),否则数据库调优不是一种"一劳永逸"的操作.您应该定期监视并可能进行调整,以避免更改数据会降低性能.
除非绝对必要,否则不要对您的数据库进行裸查询.尝试控制可以运行的查询.如果某个经理可以参加并且只是运行,你作为DBA的工作会更加困难:
select * from very_big_table order by column_without_index;
Run Code Online (Sandbox Code Playgroud)
在您的数据库上.
如果管理员希望能够运行即席查询,请为他们提供克隆的DBMS(或副本),以便您的真实用户(需要性能的用户)不受影响.
不要使用union什么时候union all就够了.如果您知道两个联合选择之间不存在重复,那么让DBMS尝试删除它们就没有意义了.
同样,select distinct如果要检索所有主键列(或唯一约束中的所有列),请不要在表上使用.有没有在这种情况下重复的可能性,所以,再一次,你问的DBMS做不必要的工作.
示例:我们的客户select distinct *在其中一个表上使用了视图.查询视图需要50秒.当我们用视图开始替换它时select *,时间降到亚秒级.毋庸置疑,我拿出一瓶好红酒:-)
尽量避免尽量避免select *.换句话说,只获取您需要的列.当您在本地PC上使用MySQL时,这几乎没什么区别,但是当您在加利福尼亚州有一个应用程序查询内蒙古的数据库时,您希望尽可能减少通过线路发送的流量.
| 归档时间: |
|
| 查看次数: |
1155 次 |
| 最近记录: |