保持简单即最优 Mysql的部署原则
今天读到
When should you store serialized objects in the database?
，
其中针对
FriendFeed使用Mysql来存储
作为引题，
建议在考虑此方案时一定要三思。为什么？参考这里
Kiss KISS KISS
. 其实
Schema-Less没有错，但不能什么场景都上此方案，要
分析利弊，减少不必要的应用层复杂度。
文中提到的Serialized objects的保存技术，就是(entity-attribute-value) EAV, 说一下总结的缺点：
1.它对搜索不友好（都压缩存在一字段里，肯定不能搜索），这确实是一个问题。FriendFeed使用变相index，解决了它需要解决的问题。但只能是规避。
2.Select精确选择字段是不成了，每次都是SELECT * from xx,当然使用Memcache可以很少的解决此问题。
3.不
能加约束(constraints)，应用层需要作校验，其实就是增加了数据层的复杂库。
4.如果使用Json，不能使用Number和IP的原始形式存储，必须转换成String。这点好像不是那么重要，因为我们可以使用的文本协议有很多。比如Google的
protobuf
其实最重要的原则在Kiss KISS KISS
中已经说的很清楚。对于刚开始的应用，使用Master-slaver足以。不要使用什么"优化"，那些
其实就是"扯淡"。对于Scaling out方案更是应该简单有效为主，说白了，对于Mysql而言，一台Master及一台或几台slaver就是"最佳方案"。
相关文档：
1. 连接mysql:
mysql -h 主机地址 -u 用户名 －p
2.退出mysql:exit
3. 修改密码:
mysqlbinmysqladmin -uroot -p(oldpassword) password newpassword
4.增加用户：
添加一个用户test1 密码为ABC；让他可以在任何主机上登录,并对所有数据库有查询、插入、修改、删除的权限。首先用以root用户连入
mysql,然后键入以下命 ......
原理
QueryCache(下面简称QC)是根据SQL语句来cache的。一个SQL查询如果以select开头，那么MySQL服务器将尝试对其使用
QC。每个Cache都是以SQL文本作为key来存的。在应用QC之前，SQL文本不会被作任何处理。也就是说，两个SQL语句，只要相差哪怕是一个字符（例如大小写不一样；多一个空格等），那么这两个SQL将使用不同的一 ......
我有一个表
CREATE TABLE `test1` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(20) NOT NULL,
`desc` varchar(100) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
（1）以下查询会报错误：[Err] 1221 - Incorrect usage of UNION and ORDE ......
表：
CREATE TABLE `user` (
`id` int(5) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(10) DEFAULT NULL,
`password` varchar(10) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM AUTO_INCREMENT=4 DEFAULT CHARSET=latin1
其中有数据为：
1 name1 123456
2&nbs ......
net start mysql //启动mysql服务
net stop mysql //停止mysql服务
mysqld-nt --remove //删除mysql后台服务
mysqld-nt --install //安装mysql后台服务
mysqld-nt可以换成mysqld-max-nt或mysqld
mysql -u root ......
