集群环境下慎用本地缓存。 用户1在机器A上看到100条记录，用户2在机器B上看到的却是90条记录。 你会说你的业务允许两边看到不一样。 是的，两个用户看到的不一样不要紧。 但是同一个用户看到不一样的话，用户体验会非常差，差到要骂人。 例子是：用户1在机器A上提交表单删除100条记录，服务端处理完毕后让浏览器跳转(Redirect after Submission)，负载均衡将这个请求跳转到机器B上，机器B上的本地缓存没变，所以仍然是删除前的记录数。 用户1看到这个结果，脑子里只有一个想法：删除没起作用。 所以，集群环境下使用本地缓存，一定要保证同一个用户先后访问的是同一台机器。
datetime: 1001年到9999年，无时区 timestamp: 1970年到2038年，支持时区的概念 timestamp比datetime更省空间。
‘High Performance MySQL’ 虽然说了 “Avoid NULL if possible”，但也说了 引用 “The performance improvement from changing NULL to NOT NULL is usually small”. 我针对这个做了下benchmarking. 性能差别确实很小。请看这里的末尾部分。 业务上说，有很多字段确实既要索引，又可能为空。对于这种情况，该NULLABLE就NULLABLE吧，没必要为了一点点性能上的收益而使用各种默认值给代码留坑。
typeahead.js的样例文档很不详细，必须查API，而API也写得比较简略。 我这里给一个比较典型的样例，供参考。 典型用况：修改一条person记录。服务端要你上传personId参数, 但用户只记得personName; 这时你要让用户在一个输入框里输入personName, 搜索出person信息，用户选中一个记录，系统再在另一个只读的输入框里记录被选中的personId, 最后提交表单上传到服务端。 表单DOM: <form> <table> <tr> <td>Person Name</td> <td><input type="text" class="typeahead" name="personName" id="personNameInput" placeholder="输入Person Name搜索"/> </td> </tr> <tr> <td>Person ID</td> <td><input type="text" name="personId" id="personIdInput" readonly/> </td> </tr> … </table> </form> 其实也可以只提供一个输入框：用户输入Person Name并选择后，系统在输入框中显示Person ID. 但Person Name和Person ID一个是字符串类型，一个是数字类型。 遇到这种情况，typeahead.js会有个bug: 第一次搜索正常，清空输入框再次搜索就会报JS语法错误。 typeahead相关javascript: var persons = new Bloodhound({ datumTokenizer: Bloodhound.tokenizers.obj.whitespace(‘personName’), //服务端返回的json中， Person Name对应的字段叫personName …
虽然文档让人读起来很痛苦，但功能很全，社区也很大。推荐使用。
jquery表单处理建议使用malsup出的jQuery Form Plugin，还可以。
从SQL性能来说，两者是差不多的。有人做过benchmarking. http://blog.csdn.net/yunhua_lee/article/details/7038780 性能方面有一点可以注意：由于char类型字段可以一次性分配到固定长度的空间，系统一般会给它分配一段连续的空间，这样的话数据一般不会被fragmentation, 对性能有一定好处。 至于存储空间，一般都会用varchar以避免浪费空间，定长的类型则可以用char.
int(1)和int(20)的存储长度是一样的，都是32位。 1和20的区别仅仅在于：mysql command-line client在显示数据时显示多少位。
测试要解决的问题 索引字段上是否存在空数据，对查询性能的影响有多大？ 基本步骤概括 测试的准备可以分为两大部分：准备测试数据和配置smack文件。 Super Smack和其他的一些benchmark工具一样，可以把“测试数据准备”也做了，包括按需建表、导入数据等等。我原本也想让Super Smack把这一步包了，但经过反复尝试后还是放弃了： 1. Super Smack的建表和导数据的触发条件比较复杂，又老是出各种各样的错，很难解决。与其让它代劳，还不如自己执行load data更可控。 2. 在测试执行过程中临时删表(drop)、建表、导数据，这种方案本身并不可取。日常开发中，我们的表本来就建好了，不需要依赖测试工具来临时创建，而且我们也不能容许测试工具在测试过程中或测试完成后自动删除表格. 所以， 我建议使用的基本方案是： 1. 自己手动完成测试数据的准备。 2. Super Smack只管执行测试语句。 测试数据准备 –建两张表，一张允许索引字段为空，另一张不允许为空 drop table if exists index_nullable; drop table if exists index_not_nullable; create table index_nullable ( id bigint unsigned not null auto_increment, name varchar(50) default null, key idx_name (name), primary key(id) ); create table index_not_nullable …
一次使用Super Smack进行MySQL benchmarking的完整经历 – 下篇：运行测试 Read More »
字段长度越小越好 字段长度越大，占用的内存、磁盘空间越大，读写时的I/O代价就越高, 同时占用的cpu周期越多。 所以，能用int, 就别用bigint. 不过，benchmarking表明，这个差别其实也不是很大。 表中数据量 操作 并发数 int类型的QPS bigint类型QPS N/A 逐渐插入100条数据到空表中 100 1092 1071 1百万 查询 100 5615 5451 注1：阿里云服务器，CPU 2核, 内存4GB, 64位CentOS, MySQL版本5.1.73,InnoDB 注2：每轮执行完后都会重启MySQL, 以消除缓存的影响 字段类型越简单越好 字段类型越复杂，占用的cpu周期越多；复杂类型的字段处理起来可能还有额外的逻辑，导致更加耗时。比如varchar类型的大小比较会牵涉到charset和collation，逻辑相对复杂，性能不如int类型。 所以， 1. 能用int, 就别用varchar 2. 如果对精度要求不高，能用float/double, 就不要用decimal 这里有人对“把IP存成varchar还是unsigned int”做了下benchmarking. 他说, 引用 Storing IPs as a string, besides requiring more disk space, takes 9% longer than …