MySQL: datetime v.s. timestamp
datetime: 1001年到9999年,无时区 timestamp: 1970年到2038年,支持时区的概念 timestamp比datetime更省空间。
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 …
MySQL中一个被索引了的列,如果在某些行的数据是null,这对性能的影响倒底有多大? 这个需要做下benchmarking才知道。 所有相关工具中, mysqlslap应该是最轻量的; 但它的可控性实在太弱,连让测试者自己造数据都做不到。 经过比较后,我发现最适合的工具应该是Super Smack. 用它做完测试后,结论很简单:被索引列是否可空,对性能的影响很小。 对我来说,更大的收获是学会了用专门的工具进行sql Benchmarking. 由于Super Smack是一个非常简陋的软件,安装、使用它的过程非常痛苦,痛苦到不停地想放弃。 然而。。。还是。。。 废话少说,先说下安装。 在64位CentOS上安装Super Smack 1.下载 传说中的 Tony Bourke维护的版本已经废了(网站都关了),我们只能从这里下载: https://github.com/tmountain/Super-Smack 2.安装mysql client相关的lib 直接./configure会出一堆错。你要先安装 yum install mysql-devel 由于Super Smack不会去lib64目录下找lib, 你还得把相关lib“复制”到/usr/lib目录中。 ln -s /usr/lib64/mysql/libmysqlclient_r.so.16.0.0 /usr/lib/libmysqlclient.so 3. 还要改一下源码中的一个头文件 在dictionary.h加入 #include <string.h> 4. 接下来正常安装 ./configure –with-mysql make make install 5.试运行 #从自带的smack中复制一个出来,免得把原来的改坏了 cp smacks/select-key.smack smacks/my.smack 接下来修改my.smack里面的mysql配置,包括client admin和client smacker1的user, pass, …
一次使用Super Smack进行MySQL benchmarking的完整经历 – 上篇:安装 Read More »