文章851
标签121
分类10

关于MySql中explain结果filtered的理解

MySql explain语句的返回结果中,filtered字段要怎么理解?

MySql5.7官方文档中描述如下:

The filtered column indicates an estimated percentage of table rows filtered by the table condition. The maximum
value is 100, which means no filtering of rows occurred. Values decreasing from 100 indicate increasing amounts of filtering. rows shows the estimated number of rows examined and rows × filtered shows the number of rows joined with the following table. For example, if rows is 1000 and filtered is 50.00 (50%), the number of rows to be joined with the following table is 1000 × 50% = 500.

这段文字不是很好理解,举例来说,有如下三个查询语句的explain结果,针对bc表的显示filtered100,而针对a表的显示是18

select_typetabletypekeykey_lenrowsfiltered
PRIMARYarangesearch417418.00
PRIMARYbeq_refPRIMARY41100.00
PRIMARYcALLPRIMARY41100.00

我们可以怎么理解filtered的值呢?从filtered的值中得出什么结论呢?到底是100更好还是18更好?

首先,这里的filtered表示通过查询条件获取的最终记录行数占通过type字段指明的搜索方式搜索出来的记录行数的百分比。

以上图的第一条语句为例,MySQL首先使用索引(这里的typerange)扫描表a,预计会得到174条记录,也就是rows列展示的记录数。接下来MySql会使用额外的查询条件对这174行记录做二次过滤,最终得到符合查询语句的32条记录,也就是174条记录的18%。而18%就是filtered的值。

更完美的情况下,应该是使用某个索引,直接搜索出32条记录并且过滤掉另外82%的记录。

因此一个比较低filtered值表示需要有一个更好的索引,假如type=all,表示以全表扫描的方式得到1000条记录,且filtered=0.1%,表示只有1条记录是符合搜索条件的。此时如果加一个索引可以直接搜出来1条数据,那么filtered就可以提升到100%`。

由此可见,filtered=100%确实是要比18%要好。

当然,filtered不是万能的,关注执行计划结果中其他列的值并优化查询更重要。比如为了避免出现filesort(使用可以满足order by的索引),即使filtered的值比较低也没问题。再比如上面filtered=0.1%的场景,我们更应该关注的是添加一个索引提高查询性能,而不是看filtered的值。

参考内容:

MySQL :: MySQL 5.7 Reference Manual :: 8.8.2 EXPLAIN Output Format

innodb - What is the meaning of filtered in MySQL explain? - Database Administrators Stack Exchange

/var/spool/postfix/maildrop 小文件过多解决办法

由于linux在执行cron时,会将cron执行脚本中的outputwarning信息,都会以邮件的形式发送cron所有者, 而我的服务器中关闭了postfix,导致邮件发送不成功,全部小文件堆积在了maildrop目录下面。如果sendmail或者postfix正常运行,则会在/var/mail目录下也会堆积大量的邮件。

此问题也会导致系统innode占用过多,导致创建文件失败。

解决办法:

sed -i 's$MAILTO=root$MAILTO=""$g' /etc/crontab
/etc/init.d/crond restat

删除多余的小文件:

find /var/spool/postfix/maildrop/ -type f |xargs rm -rf

为什么用GIF做埋点

使用GIF上报的原因

向服务器端上报数据,可以通过请求接口,请求普通文件,或者请求图片资源的方式进行。只要能上报数据,无论是请求GIF文件还是请求js文件或者是调用页面接口,服务器端其实并不关心具体的上报方式。那为什么所有系统都统一使用了请求GIF图片的方式上报数据呢?

防止跨域

一般而言,打点域名都不是当前域名,所以所有的接口请求都会构成跨域。而跨域请求很容易出现由于配置不当被浏览器拦截并报错,这是不能接受的。但图片的src属性并不会跨域,并且同样可以发起请求。(排除接口上报)

防止阻塞页面加载,影响用户体验

通常,创建资源节点后只有将对象注入到浏览器DOM树后,浏览器才会实际发送资源请求。反复操作DOM不仅会引发性能问题,而且载入js/css资源还会阻塞页面渲染,影响用户体验。

但是图片请求例外。构造图片打点不仅不用插入DOM,只要在js中new出Image对象就能发起请求,而且还没有阻塞问题,在没有js的浏览器环境中也能通过img标签正常打点,这是其他类型的资源请求所做不到的。(排除文件方式)

相比PNG/JPGGIF的体积最小

最小的BMP文件需要74个字节,PNG需要67个字节,而合法的GIF,只需要43个字节。

同样的响应,GIF可以比BMP节约41%的流量,比PNG节约35%的流量。

并且大多采用的是1*1像素的透明GIF来上报

1x1像素是最小的合法图片。而且,因为是通过图片打点,所以图片最好是透明的,这样一来不会影响页面本身展示效果,二者表示图片透明只要使用一个二进制位标记图片是透明色即可,不用存储色彩空间数据,可以节约体积。

">