我们知道Oracle的统计信息将严重影响CBO对执行计划的选择，针对不同大小的表制定收集规则并且定期执行是非常重要的。Oracle通过如下脚本即可收集统计信息：
BEGIN
DBMS_STATS.GATHER_TABLE_STATS(ownname =>'ZBDBA',
tabname =>'TEST',
estimate_percent =>30,
method_opt =>'for all columns size repeat',
no_invalidate =>FALSE,
degree =>8,
cascade =>TRUE);
END;
/
这里特别需要注意method_opt参数。Oracle官方性能优化博客专门对此参数进行了讲解。有兴趣的同学可以去看看，不然容易掉坑。
这里再贴一个自动化收集脚本
DECLARE
CURSOR STALE_TABLE IS
SELECT OWNER,
SEGMENT_NAME,
CASE
WHEN SIZE_GB < 0.5 THEN
30
WHEN SIZE_GB >= 0.5 AND SIZE_GB < 1 THEN
20
WHEN SIZE_GB >= 1 AND SIZE_GB < 5 THEN
10
WHEN SIZE_GB >= 5 AND SIZE_GB < 10 THEN
5
WHEN SIZE_GB >= 10 THEN
1
END AS PERCENT,
8 AS DEGREE
FROM (SELECT OWNER,
SEGMENT_NAME,
SUM(BYTES / 1024 / 1024 / 1024) SIZE_GB
FROM DBA_SEGMENTS
WHERE OWNER = 'SCOTT'
AND SEGMENT_NAME IN
(SELECT /*+ UNNEST */ DISTINCT TABLE_NAME
FROM DBA_TAB_STATISTICS
WHERE (LAST_ANALYZED IS NULL OR STALE_STATS = 'YES')
AND OWNER = 'SCOTT')
GROUP BY OWNER, SEGMENT_NAME);
BEGIN
DBMS_STATS.FLUSH_DATABASE_MONITORING_INFO;
FOR STALE IN STALE_TABLE LOOP
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME => STALE.OWNER,
TABNAME => STALE.SEGMENT_NAME,
ESTIMATE_PERCENT => STALE.PERCENT,
METHOD_OPT => 'for all columns size repeat',
DEGREE => 8,
GRANULARITY => 'ALL',
CASCADE => TRUE);
END LOOP;
END;
/
好了，扯太远，看看mysql的统计信息。引用percona官方博客的一段话：
An InnoDB table statistics is used for JOIN optimizations and helping the MySQL optimizer choose the appropriate index for a query. If a table’s statistics or index cardinality becomes outdated, you might see queries which previously performed well suddenly
show up on slow query log until InnoDB again updates the statistics. But when does InnoDB perform the updates aside from the first opening of the table or manually running ANALYZE TABLE on it? The 2 instances below are documented from the MySQL and InnoDB
plugin’s manual:
Metadata commands like SHOW INDEX, SHOW TABLE STATUS and SHOW [FULL] TABLES (or their corresponding queries from INFORMATION_SCHEMA.TABLES and INFORMATION_SCHEMA.STATISTICS)
When 1 / 16th of the table or 2Billion rows has been modified, whichever comes first. ./row/row0mysql.c:row_update_statistics_if_needed
If you or an application constantly executes SHOW [FULL] TABLES or SHOW TABLE STATUS on many a large tables, this can affect your server especially if the random index dives had to be read from disk. Here is an example of SHOW TABLE STATUS FROM schema taking
away a couple of seconds on execution time.
# Time: 110923 1:48:17 # [email protected]: user1[user1] @ [172.20.6.1] # Thread_id: 10140441 Schema: db1 Last_errno: 0 Killed: 0 # Query_time: 12.277786 Lock_time: 0.000068 Rows_sent: 294 Rows_examined: 294 Rows_affected: 0 Rows_read: 294 # Bytes_sent: 34187 Tmp_tables: 1 Tmp_disk_tables: 0 Tmp_table_sizes: 0 SET timestamp=1316767697; show table status from `db1`;
As you can see db1 has about 294 tables and it took the server 12 seconds to update all the tables’ statistics. Luckily, this can be controlled with Percona Server with the variable innodb_stats_auto_update (from MySQL Community 5.1.17 a similar variable exist
called innodb_stats_on_metadata, for Percona Server where both variables exist, both should be 0 if you want to disable the feature). When set to 0, automatic updates to the table statistics (items 1 and 2 above) is disabled unless ANALYZE TABLE is ran or
during first open of the table.
On my next post, I will discuss the effects of disabling the feature and how you or your application should compensate.
通过上述描述，mysql不需要我们手动的去收集统计信息。通过一些列的命令将会自动触发统计信息的收集。innodb_stats_on_metadata参数用来控制此行为，设置为false时不更新统计信息
版权声明：本文为博主原创文章，未经博主允许不得转载。