数据库的模糊查询

明确的告诉你。。。就这么直接检索不行。。。

大家不知道看明白没有：这是用确定数据检索不确定数据。。。不是你们说的用通配符能解决的事情。

数据检索的本质是用模式（就是不确定数据），检索符合模式的确定值。

确定性就是唯一性，而模式是不确定的。。。

我们输入IG84317183的时候，这是个确定值，是唯一的。而这个唯一值可能属于的模式是无穷的或者是数量非常巨大的

从数学上来说，怎么可能用确定值用检索不确定值？

就像你说的：可能是IG8，而这几个问号可能的组合就有10万。也可能是IG8431，或者其他。

所以很简单，唯一可行的方法是倒过来，用你数据库内的内容来匹配这个确定值。因为虽然模式是不确定的，但是你数据库内储存的是有限的确定的。

首先将你数据库内的占位符“？”，替换成通配符，如果“？”只可以代表一位数则替换为“_”或者“？”本身，如果一个“？”可以代表几个字符则替换为“%”或者是“”。因为不知道你的库规不规范，如果是规范的不知道的位数都标识为IG8这种，长度也都一样的话，可能就不用替换，因为本身就是通配符(表示一位的)。因为不知道你用的是SQL SERVER,ORACLE还是其他的。

然后我们就可以用'IG84317183' 去 LIKE 你数据库里的带通配符的模式。

很简单的语句就是：

如果有表“纸币表”，字段名是“纸币号”，则：

替换为“%”的

select from 纸币表 where 'IG84317183' LIKE REPLACE(纸币号,'','%');

也可以替换为“_”的：

select from 纸币表 where 'IG84317183' LIKE REPLACE(纸币号,'','_');

如果不替换就直接：

select from 纸币表 where 'IG84317183' LIKE 纸币号;

注意LIKE的两边跟我们平时用的是反的(一般来说是 字段 like '某个值',现在是 '某个值' like 字段，也就是说将字段中的值作为通配符表达式 )。就这样，很简单，很简单就能实现。只要你把道理想通。

但是，请你注意：这样检索出来的东西不能保证对应。还是那个道理，模式实际上是不确定的，虽然你可以数据库中检索出来，你就能说：

IG84183这条数据是IG84317183 ？？？。在现实中肯定不能，除非你在现实中有很强的业务规则对应。否则是很危险的。

数据库的开发对于后台编程程序员来说是必备能力之一了，而今天我们就一起来了解一下，关于数据库开发的设计规范都有哪些类型，北京北大青鸟希望通过对本文的阅读，大家对于数据库开发有更多的了解。

一、数据库命令规范

所有数据库对象名称必须使用小写字母并用下划线分割

所有数据库对象名称禁止使用mysql保留关键字(如果表名中包含关键字查询时，需要将其用单引号括起来)

数据库对象的命名要能做到见名识意，并且后不要超过32个字符

临时库表必须以tmp_为前缀并以日期为后缀，备份表必须以bak_为前缀并以日期(时间戳)为后缀

所有存储相同数据的列名和列类型必须一致(一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低)

二、数据库基本设计规范

1、所有表必须使用Innodb存储引擎

没有特殊要求(即Innodb无法满足的功能如：列存储，存储空间数据等)的情况下，所有表必须使用Innodb存储引擎(mysql55之前默认使用Myisam，56以后默认的为Innodb)Innodb支持事务，支持行级锁，更好的恢复性，高并发下性能更好

2、数据库和表的字符集统一使用UTF8

兼容性更好，统一字符集可以避免由于字符集转换产生的乱码，不同的字符集进行比较前需要进行转换会造成索引失效

3、所有表和字段都需要添加注释

使用comment从句添加表和列的备注从一开始就进行数据字典的维护

4、尽量控制单表数据量的大小，建议控制在500万以内

500万并不是MySQL数据库的限制，过大会造成修改表结构，备份，恢复都会有很大的问题

可以用历史数据归档(应用于日志数据)，分库分表(应用于业务数据)等手段来控制数据量大小

5、谨慎使用MySQL分区表

分区表在物理上表现为多个文件，在逻辑上表现为一个表谨慎选择分区键，跨分区查询效率可能更低建议采用物理分表的方式管理大数据

6、尽量做到冷热数据分离，减小表的宽度

MySQL限制每个表多存储4096列，并且每一行数据的大小不能超过65535字节减少磁盘IO,保证热数据的内存缓存命中率(表越宽，把表装载进内存缓冲池时所占用的内存也就越大,也会消耗更多的IO)更有效的利用缓存，避免读入无用的冷数据经常一起使用的列放到一个表中(避免更多的关联 *** 作)

以上就是关于数据库的模糊查询全部的内容，包括:数据库的模糊查询、数据库设计需要遵守的设计规范、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！