有些法式员在撰写数据库使用法式时，常专注于 OOP 及各类 framework 的利用，却忽略了根基的 SQL 语句及其「机能 (performance) 优化」问题。曾听过台湾某半导体大厂的新历程序员，所组出来的一段 PL/SQL 跑了好几分钟还跑不完;想当然，即便他的 AJAX 及 ooxx 框架用得再标致，系统机能也会让利用者无法忍耐。以下是拾掇出的一些数据库规划、SQL performance tuning 简单心得，让长年研究AJAX、一堆高深 ooxx framework，却无暇研究 SQL statement 的法式员，透过最短时间对本文的阅读，能避免踩到一些 SQL 的机能地雷。
Primary Key 字段的长度尽量小，能用 small integer 就不要用 integer。例如员工数据表，若能用员工编号当主键，就不要用成分证号码。
文字数据字段若长度不固定，如：地址，则该用 varchar 或 nvarchar。除了可节流存储空间外，存取硬盘时也会较无效率。
设想字段时，若其值无关紧要，最好也给一个默认值，并设成「不答应 NULL」(一般字段默认为「答应 NULL」)。由于 SQL Server 在存放和查询有 NULL 的数据表时，会破费额外的运算动作 [2]。
若一个数据表的字段过多，应垂直切割成两个以上的数据表，并可用同名的 Primary Key 一对多保持起来，如：Northwind 的 Orders、Order Details 数据表。以避免在存取数据时，以「集簇索引 (clustered index)」扫描时会加载过多的数据，或点窜数据时形成互相锁定或锁定过久。
替常被查询或排序的字段成立索引，如：常被看成 WHERE 子句前提的字段。
用来成立索引的字段，长度不宜过长，不要用跨越 20 个 Byte 的字段，如：地址。
不要替内容反复性高的字段成立索引，如：性别;反之，若反复性低的字段则适合成立索引，如：姓名。
不宜替过多字段成立索引，不然反而会影响到「INSERT、UPDATE、DELETE」的机能，特别是以「OLTP (联机事务处置;在线买卖)」为主的网站数据库。
若数据表存放的数据很少，就不必锐意成立索引。不然可能数据库沿着存放索引的「树状布局」(Balanced Tree) 去搜索索引中的数据，反而比扫描整个数据表还慢。
若查询时合适前提的数据良多，则透过「非集簇索引 (non-clustered index)」搜索的机能，反而 可能不如整个数据表逐笔扫描。
成立「集簇索引」的字段选择至为主要，会影响到整个索引布局的机能。要用来成立「集簇索引」的字段，务必选择「整数」类型 (键值会较小)、独一、不成为 NULL。
有些册本会提到，利用「LIKE、%」做恍惚查询时，即便您已替某个字段成立索引 (如下方代码的 CustomerID 字段)，但以常量字符开首才会利用到索引，若以万用字符 (%) 开首则不会利用索引，如下所示：
