公司：第一天站立办公，腰快断了
http://i.imgur.com/giCnEoG.jpg

家里：上海今天下雨
http://i.imgur.com/sj4iAyu.jpg

@pythonee 我看你说的觉得你是要xa prepare阶段出现内存溢出却还可以响应这样的场景，但这不可能，如果这个时候MySQL不死去可能比死去危害更大，你觉得你会写这样的软件么，就我平时碰到的错误来看，MySQL不会这样。

另外，主建冲突不是MySQL错误，是用户错误，他不会影响MySQL进程，你可以在任何时候，任意阶段制造一个这样的错误。

kill -9 mysqld 可能就是你想要的效果。 :-)

你能举个栗子么

MySQL 或者其他任意软件都可以，出错了却还可以响应。

@felinx 同意。。

为了不让更多的人受骗，我还是上了LZ的当。

难道LS的44位同学就没发现，LZ轻轻松松就两百多铜板入账么？真为你们感到捉急。

@kennedy32 好在 @realzyy 把所有该重视的参数都列出来了，并且分类清晰。如果要在自己的生产环境使用具体配置肯定要根据自己的情况调整的。

你有自增主键ID么？如果有的话：

1.假设你每次需要随机50篇文章。
2.让程序随机出100个不重复ID，之所以是100个是防止某些文章删除了，可根据情况调整。
3.用select * from post where id in (2,3,5,7,11...) limit 50;取出文章。
4.好了。即使你运气比较差，随机的100个ID里面有60篇文章被删除了，那就随他去吧，who care？

如果没有自增ID，那么就调整业务加一个，不管是针对业务需求还是数据库性能优化都有好处，之后再使用上面的方案。

Skillpages sucks!

就这点东西LZ要看20天？智商捉鸡。

哦，我理解错了。不好意思。

ls | xargs vim # 同时打开多个文件
:n [file_name] #切换文件

他们很辛苦的，一天跑到晚，还总是遭人忽视或白眼。即便这样，他们一个月也就挣万吧块。

据我使用来看，CMCC用OSX连不上，CMCC-AUTO能用OSX连上，但需要打10086开通。原因不详。

我建议你还是想办法把这些数据做成一对多，多对多形式的“源关系数据”，可能很大，但不一定要实时查询。

之后如果为了查询速度可以在“源关系数据”基础上跑一遍对“词语表”生成两个冗余列，一列存所有近义词，一列存所有的反义词。或者使用mc,redis什么的缓存起来。

随着你词库越来越大，这样的“源关系数据”维护起来方便还干净，重新生成冗余列或者缓存也方便。

@m4ker 影响如 @shiny 所说。对于复合索引没有影响。

http://dev.mysql.com/doc/refman/5.5/en/problems-with-null.html

http://dev.mysql.com/doc/refman/5.5/en/multiple-column-indexes.html

http://stackoverflow.com/questions/229179/null-in-mysql-performance-storage

http://stackoverflow.com/questions/471367/when-to-use-null-in-mysql-tables

http://books.google.com.hk/books?id=BL0NNoFPuAQC&lpg=PA81&dq=avoid%20null%20if%20possible&hl=zh-CN&pg=PA81#v=onepage&q=avoid%20null%20if%20possible&f=false

没听说过这个说法，给个来源？

你手头上没什么负责的产品的时候，我觉得随时可以离开，打长工的才觉得在一个公司必须干满三五年吧。等你找到你喜欢的工作或者公司的时候你自然会干满三五年的。

而针对你的情况，如果你是想换一个工种而不是公司，我觉得应该乘早离开。一份工作干久了会因为不舍丢弃积累的经验，或者其他用人单位因为你对你向往的工种毫无经验而换工种越来越困难，而你又不确定你将来是否可以把你现在做的事情发展成你爱做的事情，这对于你来说可能是往死胡同走。

而如果只是换个公司，我觉得还是多考虑下，新鲜感和快速成长不管去什么公司都是在一个很短暂的时间内的事情，大多数时候都是枯燥和繁琐的事情。

华为啊，好NB的公司，要是收我就好了。

白酒，啤酒，红酒我都觉得很好喝，喜欢酒散发出来的味道。我不是很能喝，讨厌酗酒。