一样了解自己管理的数据库，个人认为包含了两个方面的了解：
1，在稳定性层面来说，更多的是关注高可用、读写分离、负载均衡，灾备管理等等high level层面的措施（就好比要保证生活的稳定性）
2，在实例级别的来说，需要关注内存、IO、网络，热点表，热点索引，top sql，死锁，阻塞，历史上执行异常的SQL（好比生活品质细节）
MySQL的performance_data库和sys库提供了非常丰富的系统日志数据，可以帮助我们更好地了解非常细节的，这里简单地列举出来了一些常用的数据。
sys库是以较为可读化的方式封装了performance_data中的某些表，因此这些个数据来源还是performance_data库中的数据。
这里粗略列举出个人常用的一些系统数据，可以在实例级别更加清楚地了解MySQL的运行过程中资源分配情况。
Status中的信息
MySQL的status变量只是给出了一个总的信息，从status变量上无法得知详细资源的消耗，比如IO或者内存的热点在哪里，库、表的热点在哪里，如果想要知道具体的明细信息就需要系统库中的数据。
前提要开启performance_schema，因为sys库的视图是基于performance_schema的库的。
内存使用：
内存/innodb_buffer_pool使用概要
innodb_buffer_pool的使用情况summary，已知当前实例262144*16/1024 = 4096MB buffer pool,已使用23260*16/1024 363MB
innodb_buffer_pool已占用内存的明细信息，可以按照库\表的维度来统计
SET SESSION TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ; SELECT database_name, SUM(compressed_size)/1024/1024 AS allocated_memory, SUM(data_size)/1024/1024 AS data_memory, SUM(is_hashed)*16/1024 AS is_hashed_memory, SUM(is_old)*16/1024 AS is_old_memory FROM ( SELECT case when INSTR(TABLE_NAME,'.')>0 then replace(SUBSTRING(TABLE_NAME,1,INSTR(TABLE_NAME,'.')-1),'`','') else 'system_database' end as database_name, case when INSTR(TABLE_NAME,'.')>0 then replace(SUBSTRING(TABLE_NAME,INSTR(TABLE_NAME,'.')+1),'`','') ELSE 'system_obj' END AS table_name, if(compressed_size = 0, 16384, compressed_size) AS compressed_size, data_size, if(is_hashed = 'YES',1,0) is_hashed, if(is_old = 'YES',1,0) is_old FROM information_schema.innodb_buffer_page WHERE TABLE_NAME IS NOT NULL ) t GROUP BY database_name ORDER BY allocated_memory DESC LIMIT 10;
缓存命中率统计及冷热数据变化
查询缓存命中率相关：
information_schema.innodb_buffer_pool_stats中的数据行数是跟buffer_pool_instance一致的
也就是每个一行数据来描述一个buffer_pool_instance，这里简单取和，缓存命中率取平局值的方式来统计
需要注意的是
1，modified_database_pages是实时的，就是内存中的脏页的数量，经checkpoint之后被刷新到磁盘，因此会时大时小。
2，pages_made_young和pages_not_made_young是累积的增加的，不会减少，就是MySQL实例截止到目前位置，做了多少pages_not_made_young和pages_not_made_young。
3，hit_rate在负载较低的情况下，没有参考意义，这一点很奇怪，低负载情况下，会发现很多buffer_pool的hit_rate是0。
突然意识到，hit_rate的计算，是不是以某个时间间隔为基准，统计这个时间段内请求的命中率，如果这一小段时间内没有请求，统计出来的hit_rate就是0。
4，与其他视图不通，information_schema.innodb_buffer_pool_stats中的数据会在服务重启后清零。