您当前的位置: 首页 » MySQL/MSSQL编程 » 优化数据库前的十大问题
优化数据库前的十大问题
论坛链接
在优化你的数据库时，你可能没有用到这些细节的优点。以下是10个关于你的数据库性能的问题，需要你问问自己。
1. 假设你的数据库不需要存储特殊字符的能力，尤其是Unicode标准中规定的那些字符，你有没有在系统中把nchar类型替换成char之类的各种适用的字段类型？
2. 你是不是在用smalldatetime类型，而不是datetime？如果你不清楚这两种类型有什么区别，这是一个简单介绍：smalldatetime类型可以存储1900年1月1日至2079年6月6日的日期，而datetime类型把这一范围扩展到了1753年1月1日至9999年12月31日。你需要这么大的范围吗？
3. 你是不是例行公事地使用bit类型来代替smallint类型？如果是这样，你知道其中的代价吗？这对你的程序可能并没有影响，但smallint类型可以建立索引，bit类型不行。
4. SQL Server 2000在bit类型字段中允许空值，而且是默认的。有人希望这样，也有人不希望这样。
5. 你如何处理字段中的空值？默认方式是允许空值，但更好的办法是禁止空值，允许零长度的字符串。
6. 你想过表中能容纳的最多行数吗？你比较过这个数值和数据页的大小8060字节吗？
7. 你有没有好好利用标准字段？（去看看菜单里的工具->选项->标准字段）
8. 你的表中有没有一个时间戳字段？如果没有的话，你知道什么时候这种字段会有用处吗？
9. 你的表都有区块索引吗？你知道一个表什么时候应该有区块索引，什么时候一文不值吗？
10. 你在命名存储过程时有没有用sp_前缀？你有没有意识到这样做给性能带来了什么影响？
要避免这些常见的开发问题，一个很好的办法是使用SSW的SQL Auditor，它能审核的事情远远不止我所列出的10条。SQL Auditor的价格很合理，最好的一点是你可以下载测试版，试用20次之后再付费。SSW的试用策略吸引了我，可能因为我经常下载一些限制14天使用的试用软件，之后忘记运行它，直到试用期过去。
1. 假设你的数据库不需要存储特殊字符的能力，尤其是Unicode标准中规定的那些字符，你有没有在系统中把nchar类型替换成char之类的各种适用的字段类型？
2. 你是不是在用smalldatetime类型，而不是datetime？如果你不清楚这两种类型有什么区别，这是一个简单介绍：smalldatetime类型可以存储1900年1月1日至2079年6月6日的日期，而datetime类型把这一范围扩展到了1753年1月1日至9999年12月31日。你需要这么大的范围吗？
3. 你是不是例行公事地使用bit类型来代替smallint类型？如果是这样，你知道其中的代价吗？这对你的程序可能并没有影响，但smallint类型可以建立索引，bit类型不行。
4. SQL Server 2000在bit类型字段中允许空值，而且是默认的。有人希望这样，也有人不希望这样。
5. 你如何处理字段中的空值？默认方式是允许空值，但更好的办法是禁止空值，允许零长度的字符串。
6. 你想过表中能容纳的最多行数吗？你比较过这个数值和数据页的大小8060字节吗？
7. 你有没有好好利用标准字段？（去看看菜单里的工具->选项->标准字段）
8. 你的表中有没有一个时间戳字段？如果没有的话，你知道什么时候这种字段会有用处吗？
9. 你的表都有区块索引吗？你知道一个表什么时候应该有区块索引，什么时候一文不值吗？
10. 你在命名存储过程时有没有用sp_前缀？你有没有意识到这样做给性能带来了什么影响？
要避免这些常见的开发问题，一个很好的办法是使用SSW的SQL Auditor，它能审核的事情远远不止我所列出的10条。SQL Auditor的价格很合理，最好的一点是你可以下载测试版，试用20次之后再付费。SSW的试用策略吸引了我，可能因为我经常下载一些限制14天使用的试用软件，之后忘记运行它，直到试用期过去。