MYSQL表对象的字典缓存

那么一般情况下，只有对表结构、依赖关系、表定义等方面进行修改之后，因为这个表的版本被更新了，如果继续将其缓存的话是不安全的，或者是错误的，或者导致一些不可预知的问题，所以这种情况下这个表对象的缓存SHARE对象必须要从缓存中删除，同时要删除它上面所以被实例化的表对象缓存结构，这样当其它用户在等待表对象的修改操作完成之后（因为修改过程中这个表是被上了锁的，进行操作需要等待），又一次像上面叙述的一样，首先是从缓存中找这个表的缓存对象，如果找不到的话再从数据字典（系统表）中读取进来，然后继续操作即可。

到这里关于表的缓存及一些其它的内容就叙述完了。

总结：

1）上面提到的表的缓存机制有很大的好处的，因为它不是全字典缓存（全字典缓存的意思就是在数据库启动时将所有的数据字典信息都一次性载入内存中来，这样在使用过程中就效率非常高，但在DDL操作方面有很大的不足），它是用到的时候再载入，修改之后直接删除有可能再重新载入，这样的实现方式减少了DDL操作或DDL的回滚导致的字典缓存维护工作的代价。

2）有效的利用了内存空间，因为可以通过设置表对象缓存空间的大小来控制内存的使用情况，同时只有用到的对象才会被载入到内存中，提高了内存的利用率。

3）上面所叙述的MYSQL表缓存实现方案虽然说是比较先进的，但是在效率方面还是有些优化的空间的，比如上面提到的，在用来控制缓存空间大小是根据实例的个数来计算的，在系统中默认最大值是400个，如果超过这个值系统会自动淘汰一些不常用的实例，但是如果一个表的定义非常大，那么并发情况下，有可能会建立很多个实例，假设接近400个，那么这样算下来有可能会将操作系统的内存用光，这个是不可控制的，也是不可预期的。对于SHARE的缓存也是一样，如果一个用户访问了很多不同的定义很大的表，也会有同样的问题。

4）从上面也可以看出，为了实现插件式的数据库，其实还是有一些效率的代价的，在表的缓存方面，中间加入了一层SHARE的缓存，真正用到的时候还需要实例化，因为每一个用户的操作及不同时间的状态都是不同的，所以每一个用户必须要再在SHARE的基础上实例化一个新的对象出来，这样就给内存、CPU带来了一定程序上的浪费及压力。

问题的解决：

1）SHARE缓存：我个人认为有一个更好的办法来很精确通过具体的空间大小来管理表缓存空间，因为对于SHARE而言，它是静态的，它是个结构体，通过使用计数来控制内存的使用，有可能会造成内存用光的情况，那么对于SHARE对象，完全可以把它流式化（扁平化），也就是说等把这个结构体的大小计算出来，申请相应的空间，将结构体中的所有信息都按照固定的顺序写入到这块内存中，那么这样一个SHARE所占的空间大小就固定了，这样可以完全通过设置空间大小来管理表对象缓存空间了，这样上面提到的内存用光的问题就自然解决了，当然这个大小需要根据计算机的内存大小合理的设置，至少不会出现不可预料的问题。

2）TABLE缓存：TABLE实例的缓存同样存在上面的问题，解决方案与上面的思想差不多，因为这个对象是一直被用的，它是一个实例，所以就不能直接像上面一样，将其流式化，而是可以通过申请一片连接的空间，这个实例中所有的指针或者其成员的值都指向（有可能要对齐）这个空间中的指定位置，这样这个结构体的使用没有任何改变，但其占用的空间大小是固定的，同样可以通过用户手动设置TABLE实例缓存空间的大小来管理缓存空间，这样也避免了表定义太大导致内存用光的问题。

上一页  1 2 3