free361的博客

这个sql语句正常不应该加group by，但是我理解在一一对应的情况下加group by不应该影响结果。 machine_type_id存在的情况下其他数据都可以获取到title，只有最后一个没有拿到。经测试如果将其他null的值改为19，则这个值就拿到title了，下一个值会拿不到。如果将order by改为其他字段，则所有数据都正常。如果不用group by则正常。 目前还没有思路，不知道什么问题 ...

需求：首页热门栏目需要随机显示几条信息 方案1：order by rand()，全表扫描 SELECT SQL_NO_CACHE * FROM `house_rent` order by rand() limit 10(共 1 行, 查询花费 0.1069秒) explain SELECT * FROM `house_rent` order by rand() limit 1id    se

当要索引字段长度较长，不利于放入索引时，使用前缀索引。可以为索引字段指定长度，即在该字段前n个字符上生成索引。 那么具体取多少个字符做索引？ 1.计算该字段选择性 = a 2.分别计算该字段取n个字符的选择性 3.当n与a接近，或n增大对a影响较小时，记得到最优的n 实例： 表house_rent，title字段没有索引，使用选择性计算方法计算前缀个数 //查询分析

mysql建表 CREATE TABLE IF NOT EXISTS `apachelog` ( `id` int(11) NOT NULL AUTO_INCREMENT, `username` varchar(100) COLLATE utf8_bin DEFAULT NULL, `status` varchar(100) COLLATE utf8_bin DEFAULT NULL

在建立索引时有时要考虑的排序字段，将排序字段加入索引也可以缩小搜索范围 explain select * from table_name where skin_id=4 order menu_order desc 上图可见，对应没有索引的sql，按menu_order 倒序，使用到了filesort。filesort非常影响效率，在数据量不大的情况下会使用内存排序，将查询结果导入内存，

有时某字段明明设置了索引，sql也用到该字段做条件，但最终却没有使用索引。 上图，cid为索引，选择性为59 explain select * from table_name where cid=142 上图显示，可用索引cid，但实际索引null。 这是mysql查询优化器决定的，因为基数太小，只有59条。这种情况下如果使用索引，相当于多引入了一个表，

select c.*,max(cb.last_follow_time) as last_follow_time,cb.create_time as block_create_time from c_block cb left join customer c on c.id=cb.customer_id where cb.staff_id=76 and cb.give_up_time is null

在一次慢查询检查中发现一条超过30秒的语句，当时详细记录了优化过程，在此分享我的优化过程 //原始查询语句 select s.time,m.uid,m.cid,m.content_id,c.table_name,c.pid,f.content_code,m.set_date from h_slave as s left join h_master as m on m.id = s.rm_id

所谓延迟关联，就是本来通过一个比较耗时的条件搜索到全部数据的sql，分解为先通过该条件搜索到对应id，再用id内联原表取得所有字段值 例1：使用延迟关联方式，比直接搜索快一倍多 select * from house_rent where c_datetime>'2013-06-08' and title like "%宣庆街%"(共 25 行, 查询花费 0.1435 秒) id   se

mysql中经常需要ip地址字段，如何设计字段才能称得上是品学兼优的好设计？下面分析几种设计模式 方案1：varchar(15)-varchar(255) 大部分新手只要是字符串字段，不管什么类型，全部varchar(255)。有些考虑深一步用varchar(15)，其实15跟255在这里没有区别，因为ip地址是15个字符，mysql实际保存时一定会先存15个字符，后面还会跟一个长度字符。所以