业务性能测试中，如果一个查询接口，譬如根据用户id去查询一个用户的详细信息，jmeter脚本中是否需要将用户id进行变量化，（系统中不涉及redis之类的缓存）用户信息都是从数据库直接查询的；
如果jmeter脚本中将用户id写死，就并发查询同一个用户的信息，吞吐量会不会有什么不同
用户表 userinfo 18W数据，idb文件大小168M
分别测试如下场景
1.将用户id变量化，并发去获取18W用户的信息
2.将用户id写死，并发去获取一个用户的信息
两种场景下测试的吞吐量居然是一样的
问题一：难道mysql没有开启缓存？？
我们的业务库 的mysql用的是innodb引擎mysql的环境分两种
一种是查询缓存：将查询sql、查询结果集存储在内存中查询了下数据库的配置，query_cache_type为OFF，查询缓存未打开
第二种是innodb的内存缓冲池
（1）缓冲池(buffer pool)是一种常见的降低磁盘访问的机制；
（2）缓冲池通常以页(page)为单位缓存数据；一页的大小为16k(innodb_page_size)
通过show engine innodb status查询两种场景下缓冲池队长度的变化
第一种场景：将用户id变量化，并发去获取18W用户的信息database pages增加了4000左右
第二种场景：将用户id写死，并发去获取一个用户的信息database pages增加了3左右
这样来看的话，虽然没有用到查询缓存，但是innodb的缓冲池应该起作用啦，
第一种场景读取的物理磁盘次数明显比较多,为啥吞吐量没区别尼难道是因为数据量太小了，100M的数据读入内存很快？？基本不会消耗IO资源？
后来换了一个500w的表，大小1.2G 也是同样的结果
这样是不是说明 如果表大小在百万内，查询请求的参数是不是都可以写死？没必要变量化。。。。，这样数据是不是可以随便构造，不用关心数据的具体取值
