关于百万级停车记录表的车牌号模糊查询，如何优化？
目前在做的停车系统，大概一个月能产生10w条停车的记录，系统已经上线3个月，预计不到一年或者更短（停车的道闸还在不断增加）就会达到百万级的数据量，主要客服需要排查车牌识别错误的情况以保证停车系统可以正常的运行，需要经常性的使用车牌号字段的模糊查询，目前的数据量，虽然使用的%$str%的形式进行模糊查询，但查询时间还挺快的，主要是担心数据量上来的时候，查询时间会比较慢，导致客服响应的效率变慢，所以现在提出几个问题：
1.以车牌号6-7个字符为一个字符串的情况，数据量大的时候模糊查询，全表检索，有没有必要进行优化？
2.优化是改成全文索引么？昨天试了下全文索引好像最小单位只能是单词，这种全拼接在一起的情况如何处理？
关于 LearnKu
粤公网安备 44030502004330号
高认可度评论：
百万对 MySQL 只是一个小数目，另外可以增加一个时间的筛选，缩小一下筛选的范围
自己插入多点假数据，试试看不就知道了
你的 str 内容是啥 ？百万的数据 都怕吗？ like '%%' 真的不推荐
把车牌拆成七个字段
百万对 MySQL 只是一个小数目，另外可以增加一个时间的筛选，缩小一下筛选的范围
ES吧
es
停车系统可以分表的吧，车开走了就挪到另一个表，保持停车表只有停车场车位那么多的数据
这种停车记录类的表可以考虑做冷热数据分离 ， 通过控制热数据表的数据量来保证查询效率
自己插入多点假数据，试试看不就知道了
是的，只查在库的车辆应该很少。。
以前学过一个叫solr的东西，不知道有用没 :relieved:
加上停车场ID或者坐标,查询范围更少
正常来说百万也不是很大的量，大量检索类型的功能建议可以了解一下： elasticsearch
ES吧 单机千万级数据量毫秒级查询速度 在数据量大了可以分布式 保证数据同步就行了 可以实现任何复杂性查询条件
百万级别mysql没什么问题，当然优化的考虑下ES
@AloneUtopia 这个想法不错，在加个默认时间段来过滤谁会查几个月以前的数据
如果没有链表操作，果断ES，ES，ES，ES，重要的事情说4遍。。。。1000万数据都不怕~
直接丢 es 完事了！！！！ 维护好MySQL和es数据一致性就行！！！