大家在安装或使用MYSQL时，会发现除了自己安装的数据库以外，还有一个 information_schema数据库。information_schema数据库是做什么用的呢，使用WordPress博客的朋友可能会想，是不是安装模板添加的数据库呀？看完本片文章后，你就会对information_schema数据库有所了解。
information_schema数据库是MySQL自带的，它提供了访问数据库元数据的方式。什么是元数据呢？元数据是关于数据的数据，如数据库名或表名，列的数据类型，或访问权限等。有些时候用于表述该信息的其他术语包括“数据词典”和“系统目录”。在 MySQL中，把 information_schema 看作是一个数据库，确切说是信息数据库。其中保存着关于MySQL服务器所维护的所有其他数据库的信息。如数据库名，数据库的表，表栏的数据类型与访问权限等。在INFORMATION_SCHEMA中，有数个只读表。它们实际上是视图，而不是基本表，因此，你将无法看到与之相关的任何文件。
information_schema数据库表说明:
SCHEMATA表：提供了当前mysql实例中所有数据库的信息。是show databases的结果取之此表。
TABLES表：提供了关于数据库中的表的信息(包括视图)。详细表述了某个表属于哪个schema，表类型，表引擎，创建时间等信息。是show tables from schemaname的结果取之此表。
COLUMNS表：提供了表中的列信息。详细表述了某张表的所有列以及每个列的信息。是show columns from schemaname.tablename的结果取之此表。
STATISTICS表：提供了关于表索引的信息。是show index from schemaname.tablename的结果取之此表。
USER_PRIVILEGES(用户权限)表：给出了关于全程权限的信息。该信息源自mysql.user授权表。是非标准表。
SCHEMA_PRIVILEGES(方案权限)表：给出了关于方案(数据库)权限的信息。该信息来自mysql.db授权表。是非标准表。
TABLE_PRIVILEGES(表权限)表：给出了关于表权限的信息。该信息源自mysql.tables_priv授权表。是非标准表。
COLUMN_PRIVILEGES(列权限)表：给出了关于列权限的信息。该信息源自mysql.columns_priv授权表。是非标准表。
CHARACTER_SETS(字符集)表：提供了mysql实例可用字符集的信息。是SHOW CHARACTER SET结果集取之此表。
COLLATIONS表：提供了关于各字符集的对照信息。
COLLATION_CHARACTER_SET_APPLICABILITY表：指明了可用于校对的字符集。这些列等效于SHOW COLLATION的前两个显示字段。
TABLE_CONSTRAINTS表：描述了存在约束的表。以及表的约束类型。
KEY_COLUMN_USAGE表：描述了具有约束的键列。
ROUTINES表：提供了关于存储子程序(存储程序和函数)的信息。此时，ROUTINES表不包含自定义函数(UDF)。名为“mysql.proc name”的列指明了对应于INFORMATION_SCHEMA.ROUTINES表的mysql.proc表列。
VIEWS表：给出了关于数据库中的视图的信息。需要有show views权限，否则无法查看视图信息。
TRIGGERS表：提供了关于触发程序的信息。必须有super权限才能查看该表。
+---------------------------------------+
| Tables_in_information_schema |+---------------------------------------+| CHARACTER_SETS || COLLATIONS || COLLATION_CHARACTER_SET_APPLICABILITY || COLUMNS || COLUMN_PRIVILEGES || ENGINES || EVENTS || FILES || GLOBAL_STATUS || GLOBAL_VARIABLES || KEY_COLUMN_USAGE || PARAMETERS || PARTITIONS || PLUGINS || PROCESSLIST || PROFILING || REFERENTIAL_CONSTRAINTS || ROUTINES || SCHEMATA || SCHEMA_PRIVILEGES || SESSION_STATUS || SESSION_VARIABLES || STATISTICS || TABLES || TABLESPACES || TABLE_CONSTRAINTS || TABLE_PRIVILEGES || TRIGGERS || USER_PRIVILEGES || VIEWS || INNODB_CMP_RESET || INNODB_TRX || INNODB_CMPMEM_RESET || INNODB_LOCK_WAITS || INNODB_CMPMEM || INNODB_CMP || INNODB_LOCKS |+---------------------------------------+

       前面的一篇我们讨论了第一种空间索引——四叉树。作为二叉排序树在二维空间的推广，四叉树是一种非常直观有效的结构。但同样，它也带来了二叉排序树的毛病，那就是当索引对象极端时，它的查找的时间复杂度会退化成线性也就是O(n)。那在一维空间我们怎么办呢？科学家发明了一种始终维护二叉树平衡的树，即左右子树之差不超过一，顾名思义，平衡二叉树。那么平衡二叉树能不能再二维空间中推广呢。类比二叉排序树这样简单推广是不可能了，所以产生了一种新的数据结构叫区域树。
       其实所谓的区域树思路非常简单，它的原理就是对各个Envelope进行排序，然后以它们为叶节点逐层向上建树，这样建立的树是严格平衡的，它的分支节点的Envelope为子节点Envelope的并。好了，那怎么排呢，每个索引对象的Envelope有一个四维参数，即x,y,width,height。如果排序，只能使用其中一个指标，或者几个指标的组合进行评价。NTS实现了这种数据结构。NTS对它的描述是一种只可以查询的R树，但对照了R树和区域树的定义的差别，NTS里面实现的这种结构与区域树更为接近，至于是否属实还有待进一步学习。对其的操作分别可以对X，Y进行排序，对X和Y的分别查询的时间复杂度为O(logn+k),然后对其查找出的节点进行匹配，最终得到的时间复杂度为log^2+k。，同时它的空间复杂度上升到了O(nlogn)。
        NTS对这种区域树的实现基本也就到此为止了。但翻阅计算几何书时，发现时间复杂度还是可以再降的，将到我们觉着不可思议，可以达到O(logn+k)。这种技术叫分散层叠。这种技术的核心思想就是在对X排序生成的区域树之后，不建立第二棵Y区域树。而是建立另一种树结构，它是针对X结构的树的存储，构造结构相同的一棵树，每棵树的节点存的是该节点子节点的Y排序，层与层之间的元素，通过指针指向不小于其的最小元素。如下图所示。有时间Happy
 kaikai计划在NTS的基础上实现分成散叠技术，也算是做一个实践吧。
         连讲了两篇空间索引，这绝对不是索引的终结，只不过从一个菜鸟的角度，我们更期待快速实现一个基本GIS系统是我们的期盼，那跃进一下，我们看看有了图形表示，有了索引之后，我们如何进行显示它们，又是如何存取它们。下一篇我们的探索领域将从NTS到Sharpmap。

当初我去面试Java的时候，面试官问： String类型的对象，是保存在堆里还是在栈里呢？
我一想，绝对不可能放在栈里的呀，就回答是在堆里。
面试官没说什么，等我出来等公交车才想起来，不是在常量池里么，哪里在堆中哦？
嗯，不知道的，请百度搜索“String 常量池”。

一个类只声明，但是没有实例化，会占用空间吗？成员函数是否分配空间？
我明白，对象在实例化时分配空间，但是成员函数并不占对象的空间呀。是所有对象共有的呀。
所以我如果仅仅声明了类，但是没有实例化，会为这个类分配空间吗？即会为这个类的成员函数分配内存吗？
在哪里分配呢？

把类的成员函数就看成是一般的函数，不同的是就是他的参数在编译是会自动增加一个this的参数传递！


如果用汇编得语言来说，变量存在与数据段，函数存在于代码段，如此说来，空间还是要分得，就算是指令，就算是只有一份，也是要空间存储得吧。


一般当我们说到“分配空间”或者“分配内存”，都是指的对数据成员分配，而不是指成员函数。
从这个意义上来说，一个类只声明但是没有实例化，是不会给分配空间的。

既然楼主问到了“成员函数是否分配空间”，那就多罗索几句。
成员函数的代码是要占用空间的，但那是在代码段，我们通常说的分配空间都是数据段。
只要写了一个类，有成员函数，就需要在代码段保存代码，即使没有实例化也需要。

另一方面，不管有多少实例，代码也只保存一份，大家共用。


一个类只要声明了，不管是否实例化对象，都会在代码段为成员函数分配空间