1. 关于MySQL表设计应该注意的问题(做了点修改)    
2.    
3. 关 于设计表时应该注意的问题   
4.    
5. 如有错误欢迎大家指出。这 段时间在家里，做了点修正。   
6.    
7. 1
8.    
9. 有 两种选择：   
10.    
11. 按照多数开发语言的命名规则。比如 （myCustomer）。   
12.    
13. 按照多数开源思想命名规 则。比如（my_customer）。   
14.    
15. 按照咱们中国 人的思想。比如（我的客户）。   
16.    
17. 第一种有个缺点，很容 易忘掉大写的字母。   
18.    
19. 第二种则比较好，每个WORD间 用下划线连接，避免遗忘。   
20.    
21. 第三种建议不要用，虽然很 好记。不觉得解析这个表的时候还需要编码转化吗？我个人理解，大家可以补充。   
22.    
23. 2
24.    
25. A．             GBK/GB2312. （适用于纯中文存储）。   
26.    
27. B．           UTF8. （适用于中英文混合存储）。   
28.    
29. C．            LATIN1。（适 用于纯英文存储）。   
30.    
31. D.     其他的。   
32.    
33. 3
34.    
35. A.                 MYISAM. （很多人说她的表级锁定会带来好多问题，其实只要设计好对应的表以及写好对应的SQL查询就没有那么大的问题。）   
36.    
37. B.                  INNODB. （如 果要用到事务，选择她不会错。至于多数人讲的MASTER/SLAVE结构上用INNODB在MASTER的选择是否正确，就要看你怎么用了。不能一味的 疯狂使用INNODB。除非你想要确保非常高可用性，   
38.    
39. ）   
40.    
41. C.                  CSV. （以 前我写过文章，关于这个引擎。个人觉得最主要的是来存储少量数据以及从EXCEL到MYSQL的转换方面会很有用。当然只要涉及到规则数据的导入，她就可 以办到。）   
42.    
43. D.                  BLACKHOLE. （觉 得最完美的用处在于MASETR/SLAVE上面，并且MASTER是一个临时的专门负责写的机器。不过缺点也很多，会与MYISAM或者INNODB或 者其他的引擎有所冲突，这点自己要做个权衡）。   
44.    
45. E.                   MEMORY. （应 该说是MYISAM的兄弟了。不过在读内存总比读磁盘的速度要快。不过要注意，它不支持动态数据类型）。   
46.    
47. F.                   FEDERATED. （典 型的分布式引擎。我以前文章中有介绍。）   
48.    
49. G.    NDB。（网 络版存储引擎。因为Replication 总是有延迟，所以如果系统容不得任何延迟，就用这个吧。）   
50. 6.0
51.    
52. I.                  其 他旧的以及新开发的引擎具体介绍：http://dev.mysql.com/doc/refman /6.0/en/storage-engines.html）。
53.    
54. 4
55.    
56. A.                  INT（一 个字节的TINYINT，两个字节的SMALLINT，三个字节的MEDIUMINT，四个字节的INT，8
57.    
58. B.                   少 于10
59.    
60. C.                   我 一般用DECIMAL或者NUMERIC来代替FLOAT 或者DOUBLE。因为老板要求精确的数字。如果不要求精确的，那就用FLOAT吧。速度快， 占空间小。（DECIMA、FLOAT(P)是动态存储。比如:DECIMAL(10 , 2 )占用 5 个 字节。FLOAT占 4
61.    
62. D.                 BLOB，TEXT,VARCHAR（一 般存放文章内容，特别是新闻网站。需要的字节数是所存储的字符长度+1
63.    
64. E.                   ENUM（在 一定范围内绝佳的代替VARCHAR和CHAR的工具，因为她只占一到两个字节。）   
65.    
66. F.                   时 间和日期类型（占3 个字节的DATE， 8 个字节的DATETIME， 4 个 字节的TIMESTAMP， 3 个字节的TIME， 1 个字节的YEAR。）。如果要存储比如‘ 1983 ’这样的年份，用YEAR明显比VARCHAR或者CHAR要节省空间。因为后者要占 5
67.    
68. G.                  BOOLEAN（用 来存储YES或者NO之类的值，占用一个字节。）   
69.    
70. H.                  关 于自增字段。目前我们的项目中涉及到好多ORDER BY RAND()操作。此类语句在数据库并发大的时候会造成CPU严重阻塞，持续产生数据库死锁！ 解决此类问题最好的办法就是利用自增字段，用程序随即生成数字序列，或者在数据库端随即生成数字序列。   
71.    
72. I.                    关 于ZEROFILL。非常好用的前置填补0
73.    
74. 5
75.    
76. A.                  在5.0 之后，只要设定字段为NOT NULL，系统自动给出默认值。对应 CHAR->’’,INT-> 0 ,BOOLEAN-> 0
77.    
78. B.                   在5.0
79.    
80. 6
81.    
82. A.                  应 该把对应的业务放在各自不同的数据库里，而不是所有业务放到一个库里面。   
83.    
84. B.                   数 据库的命名和表命名一样。   
85.    
86. 7
87.    
88. A.                  设 计表初期尽量考虑到应该建立的索引。所有建立的索引一定要测试一下，看是否有必要，否则会翻倍的减少写数据的性能。   
89.    
90. B.                   对 于只有存储0 或者 1 的 列，尽量干掉索引，单独分出两个表。一个代替 0 ，另外一个代替 1 。或者在一个字段里面用EMUM或者CHAR( 0 )或者CHAR( 1
91.    PS： 最后一个要值得注意的，就是尽量所有的字段用NOT NULL。 虽然MYSQL可以对NULL列进行索引，不过我不建议。  
92. 如果通过语句：select max(length(`test`)) from table得到的是5000，那么可以设计为varchar(6000)。注意，在mysql中表的空间设计，和物理的存储没有关系，尽管一个utf8编码的中文，占据3个字节，但是在设计的时候，设置为varchar（1）就可以了。