解决方案 »

  1.   

    建议底层用c语言,mysql可能扛不住千万级的压力,到百万级都有点慢了。
      

  2.   

    呵,谁说MYSQL对于千万级就有压力了,百万级就有点慢了,百,千万的数据,在MYSQL中只要索引运用得当,还是相当OK的
      

  3.   

    查车牌不是唯一吗, 怎么要用like。建好索引。
    如果你是想玩 查 *123**, 这样的,那就用全文索引:如,
    粤A12345, 在全文索引字段里写成 粤A A1 23 23 34 45  (连续的两个字符当成一个词,建全文索引)
    当你要查询 车牌号包含 123 的时候, 就是查询 12 23 的 交集,再还要过滤下不是连续的(如12523 这样的车牌),
      

  4.   

    谢谢,查询数据时有模糊查询,原来做项目的都用的like,现在mysql数据库做的按月份分区表,车牌号,时间列做的索引。
    但是查询上百万,时间段长的还是不理想。
      

  5.   

    谢啦,但是这个事Unix系列系统的开源库,我们现在是多用win Server系列,还得测试程序,改部署环境等相关工作。
      

  6.   

    呵,谁说MYSQL对于千万级就有压力了,百万级就有点慢了,百,千万的数据,在MYSQL中只要索引运用得当,还是相当OK的确实索引运用的好的确会让读取的时候很快,但是千万级的数据库,在插入一条数据时势必要为这条数据添加索引,那时候的空间复杂度跟时间复杂度都会很大,但是我相信大神肯定会有办法解决,以前一直没解决这问题,还请大神指点一下
      

  7.   

    呵,谁说MYSQL对于千万级就有压力了,百万级就有点慢了,百,千万的数据,在MYSQL中只要索引运用得当,还是相当OK的确实索引运用的好的确会让读取的时候很快,但是千万级的数据库,在插入一条数据时势必要为这条数据添加索引,那时候的空间复杂度跟时间复杂度都会很大,但是我相信大神肯定会有办法解决,以前一直没解决这问题,还请大神指点一下
    其实可能我之前说的也有点片面化了,每个系统各自业务不同,对表所做的操作也是不同的,如果单是重点是查询,更新操作相对较少,那我相信千万数据没有什么问题,更新操作相对较多,在建索引时取一个平衡点,还是没有什么太大问题的,现在MYSQL优化方法很多,我说了也没什么意义,自己的经验就是不断的测试,使用不同的方法(主从,分表等等),或者说缓存,用数据来说话,看得出,这位朋友对这块也是有相关经验的,有机会可以多交流.
      

  8.   

    呵,谁说MYSQL对于千万级就有压力了,百万级就有点慢了,百,千万的数据,在MYSQL中只要索引运用得当,还是相当OK的说的相当对 我的900w左右 照样ok   
     第一: http://blog.csdn.net/nevergiveuplzl/article/details/31376751   
    第二:优化分页查询语句 http://www.jb51.net/article/31868.htm (select id,title from collect where id>=(select id from collect        order by id limit 90000,1) limit 10; )
    第三:建索引
      

  9.   

    Mysql千万级的数据量还是很easy的吧,如果这点数据量都抗不住的话,那mysql也不可能这么火了 可以搭建Sphinx服务器,通过Sphinx查询
      

  10.   

    用like肯定比=慢很多。建议采用精确查询。要不可以使用Sphinx +mysql,基本上就木有问题了
      

  11.   

    1.数据表:分表处理
    2.搜索数据,sphinx+mysql
      

  12.   

    针对你的like 建议 sphinx分布式+每日(根据需求调整频率)增量索引.具体请百度.