基于索引统计数据的成本计算

有时候使用索引执行查询时会有许多单点区间，例如使用in语句就很容易产生非常多的单点区间，比如下边这个查询（下边查询语句中的…表示还有很多参数）：

 select * from t_emp where hire_date in ('1890-11-10','1990-12-10'...'1991-11-12');

很显然，这个查询可能使用到的索引就是idx_hire_date，由于这个索引并不是唯一的二级索引，所以并不能确定一个单点区间对应的二级索引记录的条数有多少，需要我们去计算。就是先获取索引对应的B+树的区间最左记录和区间最右记录，然后再计算这两条记录之间有多少记录（记录条数少的时候可以做到精确计算，多的时候只能估算）。MySQL把这种通过直接访问索引对应的B+树来计算某个范围区间对应的索引记录条数的方式称之为index dive。

只有少数几个单点区间的话，使用index dive的方式去计算这些单点区间对应的记录数也不是什么问题，如果in语句里20000个参数怎么办？这就意味着MySQL的查询优化器为了计算这些单点区间对应的索引记录条数，要进行20000次index dive操作，这性能损耗就很大，搞不好计算这些单点区间对应的索引记录条数的成本比直接全表扫描的成本都大了。MySQL考虑到了这种情况，所以提供了一个系统变量eq_range_index_dive_limit，我们看一下在MySQL5.7.35中这个系统变量的默认值：

mysql> show variables like '%dive%';
+---------------------------+-------+
| Variable_name             | Value |
+---------------------------+-------+
| eq_range_index_dive_limit | 200   |
+---------------------------+-------+
1 row in set (0.02 sec)

也就是说如果我们的in语句中的参数个数小于200个的话，将使用index dive的方式计算各个单点区间对应的记录条数，如果大于或等于200个的话，可就不能使用index dive了，要使用所谓的索引统计数据来进行估算，也叫index statistics。

怎么个估算法？像会为每个表维护一份统计数据一样，MySQL也会为表中的每一个索引维护一份统计数据，比如我们查看一下t_emp的各个索引的统计数据可以这么写：

mysql> show index from t_emp;
+-------+------------+----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table | Non_unique | Key_name       | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-------+------------+----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| t_emp |          0 | PRIMARY        |            1 | emp_no      | A         |      299645 |     NULL | NULL   |      | BTREE      |         |               |
| t_emp |          1 | idx_hire_date  |            1 | hire_date   | A         |        5590 |     NULL | NULL   |      | BTREE      |         |               |
| t_emp |          1 | idx_birth_date |            1 | birth_date  | A         |        4770 |     NULL | NULL   |      | BTREE      |         |               |
+-------+------------+----------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
3 rows in set (0.00 sec)

属性名	描述
Table	索引所属表的名称。
Non_unique	索引列的值是否是唯一的，聚簇索引和唯一二级索引的该列值为0，普通二级索引该列值为1。
Key_name	索引的名称。
Seq_in_index	索引列在索引中的位置，从1开始计数。对普通索引来说，永远都是1，对联合索引才会大于1。比如对于联合索引u_idx_day_status(insert_time,order_status,expire_time)，来说，insert_time、order_status、expire_time对应的位置分别是1、2、3。
Column_name	索引列的名称。
Collation	索引列中的值是按照何种排序方式存放的，值为A时代表升序存放，为NULL 时代表降序存放。
Cardinality	索引列中不重复值的数量。
Sub_part	的前n个字符或字节建立索引，这个属性表示的就是那个n值。如果对完整的列建立索引的话，该属性的值就是NULL。
Packed	索引列如何被压缩，NULL 值表示未被压缩。
Null	该索引列是否允许存储NULL值。
Index_type	使用索引的类型，我们最常见的就是BTREE，其实也就是B+树索引。
Comment	索引列注释信息。
Index_comment	索引注释信息。

Cardinality属性，Cardinality直译过来就是基数的意思，表示索引列中不重复值的个数。比如对于一个一万行记录的表来说，某个索引列的Cardinality属性是10000，那意味着该列中没有重复的值，如果Cardinality属性是1的话，就意味着该列的值全部是重复的。不过需要注意的是，对于InnoDB存储引擎来说，使用SHOW INDEX语句展示出来的某个索引列的Cardinality属性是一个估计值，并不是精确的。

前边说道，当in语句中的参数个数大于或等于系统变量eq_range_index_dive_limit的值的话，就不会使用index dive的方式计算各个单点区间对应的索引记录条数，而是使用索引统计数据，这里所指的索引统计数据指的是这两个值：

• 使用show table status展示出的Rows值，也就是一个表中有多少条记录。

• 使用show index语句展示出的Cardinality属性。

mysql> show table status like 't_emp';
+-------+--------+---------+------------+--------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-------------------+----------+----------------+---------+
| Name  | Engine | Version | Row_format | Rows   | Avg_row_length | Data_length | Max_data_length | Index_length | Data_free | Auto_increment | Create_time         | Update_time | Check_time | Collation         | Checksum | Create_options | Comment |
+-------+--------+---------+------------+--------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-------------------+----------+----------------+---------+
| t_emp | InnoDB |      10 | Dynamic    | 299645 |             50 |    15220736 |               0 |      9469952 |   2097152 |           NULL | 2021-08-19 07:19:44 | NULL        | NULL       | latin1_swedish_ci |     NULL |                |         |
+-------+--------+---------+------------+--------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+-------------+------------+-------------------+----------+----------------+---------+
1 row in set (0.00 sec)

结合Rows和Cardinality，我们可以针对索引列，计算出平均一个值重复多少次。

一个值的重复次数≈ Rows ÷ Cardinality

以t_emp表的idx_hire_date索引为例，它的Rows值是299645，它对应的Cardinality 值是5590，所以我们可以计算hire_date列平均单个值的重复次数就是：299645÷5590≈53（条）

此时再看上边那条查询语句：

 select * from t_emp where hire_date in ('1890-11-10','1990-12-10'...'1991-11-12');

假设in语句中有20000个参数的话，就直接使用统计数据来估算这些参数。每个单点区间大约对应53条记录，所以总共需要回表的记录数就是：20000 x 53= 1060000

使用统计数据来计算单点区间对应的索引记录条数比index dive的方式简单，但是它的致命弱点就是：不精确！。使用统计数据算出来的查询成本与实际所需的成本可能相差非常大。

大家需要注意一下，在MySQL 5.7.3以及之前的版本中，eq_range_index_dive_limit 的默认值为10，之后的版本默认值为200。所以如果大家采用的是5.7.3以及之前的版本的话，很容易采用索引统计数据而不是index dive的方式来计算查询成本。当你的查询中使用到了in查询，但是却实际没有用到索引，就应该考虑一下是不是由于eq_range_index_dive_limit值太小导致的。

InnoDB中的统计数据

我们前边唠叨查询成本的时候经常用到一些统计数据，比如通过SHOW
TABLE STATUS 可以看到关于表的统计数据，通过SHOW INDEX可以看到关于索引
的统计数据，那么这些统计数据是怎么来的呢？它们是以什么方式收集的呢？

统计数据存储方式

InnoDB提供了两种存储统计数据的方式：

• 永久性的统计数据，这种统计数据存储在磁盘上，也就是服务器重启之后这
  些统计数据还在。

• 非永久性的统计数据，这种统计数据存储在内存中，当服务器关闭时这些这
  些统计数据就都被清除掉了，等到服务器重启之后，在某些适当的场景下才会重
  新收集这些统计数据。

MySQL给我们提供了系统变量innodb_stats_persistent来控制到底采用哪种
方式去存储统计数据。在MySQL5.6.6之前，innodb_stats_persistent的值默认是
OFF，也就是说InnoDB的统计数据默认是存储到内存的，之后的版本中
innodb_stats_persistent 的值默认是ON，也就是统计数据默认被存储到磁盘中。

mysql> show variables like 'innodb_stats_persistent';
+-------------------------+-------+
| Variable_name           | Value |
+-------------------------+-------+
| innodb_stats_persistent | ON    |
+-------------------------+-------+
1 row in set (0.00 sec)

不过最近的MySQL版本都基本不用基于内存的非永久性统计数据了，所以
我们也就不深入研究。

InnoDB默认是以表为单位来收集和存储统计数据的，也就是说我们可
以把某些表的统计数据（以及该表的索引统计数据）存储在磁盘上，把另一些表
的统计数据存储在内存中。怎么做到的呢？我们可以在创建和修改表的时候通过
指定STATS_PERSISTENT属性来指明该表的统计数据存储方式：

CREATE TABLE 表名(...) Engine=InnoDB, STATS_PERSISTENT = (1|0);
ALTER TABLE 表名Engine=InnoDB, STATS_PERSISTENT = (1|0);

• 当STATS_PERSISTENT=1时，表明我们想把该表的统计数据永久的存储到磁
  盘上。

• 当STATS_PERSISTENT=0 时，表明我们想把该表的统计数据临时的存储到
  内存中。

• 如果我们在创建表时未指定STATS_PERSISTENT属性，那默认采用系统
  变量innodb_stats_persistent的值作为该属性的值。

基于磁盘的永久性统计数据

当我们选择把某个表以及该表索引的统计数据存放到磁盘上时，实际上是把
这些统计数据存储到了两个表里：

mysql> SHOW TABLES FROM mysql LIKE 'innodb%';
+---------------------------+
| Tables_in_mysql (innodb%) |
+---------------------------+
| innodb_index_stats        |
| innodb_table_stats        |
+---------------------------+
2 rows in set (0.00 sec)

可以看到，这两个表都位于mysql系统数据库下边，其中：

• innodb_table_stats存储了关于表的统计数据，每一条记录对应着一个表的统
  计数据。

• innodb_index_stats存储了关于索引的统计数据，每一条记录对应着一个索
  引的一个统计项的统计数据。

innodb_table_stats

mysql> SELECT * FROM mysql.innodb_table_stats where table_name='t_emp';
+---------------+------------+---------------------+--------+----------------------+--------------------------+
| database_name | table_name | last_update         | n_rows | clustered_index_size | sum_of_other_index_sizes |
+---------------+------------+---------------------+--------+----------------------+--------------------------+
| employees     | t_emp      | 2021-08-19 07:19:44 | 299645 |                  929 |                      578 |
+---------------+------------+---------------------+--------+----------------------+--------------------------+
1 row in set (0.00 sec)

直接看一下这个innodb_table_stats表中的各个列都是干嘛的：

列名	说明
database_name	数据库名
table_name	表名
last_update	本条记录最后更新时间
n_rows	表中记录的条数
clustered_index_size	表的聚簇索引占用的页面数量
sum_of_other_index_sizes	表的其他索引占用的页面数量

n_rows统计项的收集

InnoDB统计一个表中有多少行记录是这样的：
按照一定算法（并不是纯粹随机的）选取几个叶子节点页面，计算每个页面
中主键值记录数量，然后计算平均一个页面中主键值的记录数量乘以全部叶子节
点的数量就算是该表的n_rows值。

可以看出来这个n_rows值精确与否取决于统计时采样的页面数量，MySQL
用名为innodb_stats_persistent_sample_pages的系统变量来控制使用永久性的统
计数据时，计算统计数据时采样的页面数量。该值设置的越大，统计出的n_rows
值越精确，但是统计耗时也就最久；该值设置的越小，统计出的n_rows 值越不
精确，但是统计耗时特别少。所以在实际使用是需要我们去权衡利弊，该系统变
量的默认值是20。

mysql> show variables like 'innodb_stats_persistent_sample_pages';
+--------------------------------------+-------+
| Variable_name                        | Value |
+--------------------------------------+-------+
| innodb_stats_persistent_sample_pages | 20    |
+--------------------------------------+-------+
1 row in set (0.01 sec)

InnoDB默认是以表为单位来收集和存储统计数据的，我们也可以单独设置
某个表的采样页面的数量，设置方式就是在创建或修改表的时候通过指定
STATS_SAMPLE_PAGES属性来指明该表的统计数据存储方式：

CREATE TABLE 表名(...) Engine=InnoDB, STATS_SAMPLE_PAGES = 具体的采
样页面数量;
ALTER TABLE 表名Engine=InnoDB, STATS_SAMPLE_PAGES = 具体的采样页
面数量;

如果我们在创建表的语句中并没有指定STATS_SAMPLE_PAGES属性的话，将
默认使用系统变量innodb_stats_persistent_sample_pages的值作为该属性的值。

clustered_index_size和sum_of_other_index_sizes统计项的收集牵涉到很具
体的InnoDB表空间的知识和存储页面数据的细节，我们就不深入讲解了。

innodb_index_stats

mysql> select * from mysql.innodb_index_stats where table_name='t_emp';
+---------------+------------+----------------+---------------------+--------------+------------+-------------+-----------------------------------+
| database_name | table_name | index_name     | last_update         | stat_name    | stat_value | sample_size | stat_description                  |
+---------------+------------+----------------+---------------------+--------------+------------+-------------+-----------------------------------+
| employees     | t_emp      | PRIMARY        | 2021-08-19 07:19:40 | n_diff_pfx01 |     299645 |          20 | emp_no                            |
| employees     | t_emp      | PRIMARY        | 2021-08-19 07:19:40 | n_leaf_pages |        886 |        NULL | Number of leaf pages in the index |
| employees     | t_emp      | PRIMARY        | 2021-08-19 07:19:40 | size         |        929 |        NULL | Number of pages in the index      |
| employees     | t_emp      | idx_birth_date | 2021-08-19 07:19:44 | n_diff_pfx01 |       4770 |          20 | birth_date                        |
| employees     | t_emp      | idx_birth_date | 2021-08-19 07:19:44 | n_diff_pfx02 |     300069 |          20 | birth_date,emp_no                 |
| employees     | t_emp      | idx_birth_date | 2021-08-19 07:19:44 | n_leaf_pages |        231 |        NULL | Number of leaf pages in the index |
| employees     | t_emp      | idx_birth_date | 2021-08-19 07:19:44 | size         |        289 |        NULL | Number of pages in the index      |
| employees     | t_emp      | idx_hire_date  | 2021-08-19 07:19:40 | n_diff_pfx01 |       5590 |          20 | hire_date                         |
| employees     | t_emp      | idx_hire_date  | 2021-08-19 07:19:40 | n_diff_pfx02 |     300069 |          20 | hire_date,emp_no                  |
| employees     | t_emp      | idx_hire_date  | 2021-08-19 07:19:40 | n_leaf_pages |        231 |        NULL | Number of leaf pages in the index |
| employees     | t_emp      | idx_hire_date  | 2021-08-19 07:19:40 | size         |        289 |        NULL | Number of pages in the index      |
+---------------+------------+----------------+---------------------+--------------+------------+-------------+-----------------------------------+
11 rows in set (0.00 sec)

直接看一下这个innodb_index_stats表中的各个列都是干嘛的：

列名	说明
database_name	数据库名
table_name	表名
index_name	索引名
last_update	本条记录最后更新时间
stat_name	统计项的名称
stat_value	对应的统计项的值
sample_size	为生成统计数据而采样的页面数量
stat_description	对应的统计项的描述

innodb_index_stats表的每条记录代表着一个索引的一个统计项。我们来具体看一下一个索引都有哪些统计项：

• n_leaf_pages：表示该索引的叶子节点占用多少页面。

• size：表示该索引共占用多少页面。

• n_diff_pfxNN：表示对应的索引列不重复的值有多少。

n_diff_pfxNN其中的NN长得有点
儿怪呀，啥意思呢？
其实NN可以被替换为01、02、03… 这样的数字。比如对于联合索引u_idx_day_status(insert_time,order_status,expire_time)来说：

• n_diff_pfx01 表示的是统计insert_time这一个列不重复的值有多少。

• n_diff_pfx02 表示的是统计insert_time、order_status这两个列组合起来不重
  复的值有多少。

• n_diff_pfx03 表示的是统计insert_time、order_status、expire_time这三个列组
  合起来不重复的值有多少。

• n_diff_pfx04 表示的是统计insert_time、order_status、expire_time、id这四个列
  组合起来不重复的值有多少。

对于普通的二级索引，并不能保证它的索引列值是唯一的，此时只有在索引列上加
上主键值才可以区分两条索引列值都一样的二级索引记录。
对于主键和唯一二级索引则没有这个问题，它们本身就可以保证索引列值的
不重复，所以也不需要再统计一遍在索引列后加上主键值的不重复值有多少。

在计算某些索引列中包含多少不重复值时，需要对一些叶子节点页面进行采
样，sample_size列就表明了采样的页面数量是多少。
对于有多个列的联合索引来说，采样的页面数量是：
innodb_stats_persistent_sample_pages × 索引列的个数。

当需要采样的页面数量大于该索引的叶子节点数量的话，就直接采用全表扫
描来统计索引列的不重复值数量了。所以大家可以在查询结果中看到不同索引对
应的size列的值可能是不同的。

定期更新统计数据

随着我们不断的对表进行增删改操作，表中的数据也一直在变化，
innodb_table_stats和innodb_index_stats表里的统计数据也在变化。MySQL提供
了如下两种更新统计数据的方式：

开启innodb_stats_auto_recalc

系统变量innodb_stats_auto_recalc决定着服务器是否自动重新计算统计数
据，它的默认值是ON，也就是该功能默认是开启的。每个表都维护了一个变量，
该变量记录着对该表进行增删改的记录条数，如果发生变动的记录数量超过了表
大小的10%，并且自动重新计算统计数据的功能是打开的，那么服务器会重新进
行一次统计数据的计算，并且更新innodb_table_stats 和innodb_index_stats 表。
不过自动重新计算统计数据的过程是异步发生的，也就是即使表中变动的记录数
超过了10%，自动重新计算统计数据也不会立即发生，可能会延迟几秒才会进行
计算。

innodb_stats_auto_recalc默认为on，表示开启。

mysql> show variables like 'innodb_stats_auto_recalc';
+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| innodb_stats_auto_recalc | ON    |
+--------------------------+-------+
1 row in set (0.02 sec)

再一次强调，InnoDB 默认是以表为单位来收集和存储统计数据的，我们也
可以单独为某个表设置是否自动重新计算统计数的属性，设置方式就是在创建或
修改表的时候通过指定STATS_AUTO_RECALC 属性来指明该表的统计数据存储方
式：

CREATE TABLE 表名(...) Engine=InnoDB, STATS_AUTO_RECALC = (1|0);
ALTER TABLE 表名Engine=InnoDB, STATS_AUTO_RECALC = (1|0);

• 当STATS_AUTO_RECALC=1时，表明我们想让该表自动重新计算统计数据。

• 当STATS_AUTO_RECALC=0 时，表明不想让该表自动重新计算统计数据。

• 如果我
  们在创建表时未指定STATS_AUTO_RECALC 属性，那默认采用系统变量
  innodb_stats_auto_recalc的值作为该属性的值。

手动调用ANALYZE TABLE语句来更新统计信息

如果innodb_stats_auto_recalc系统变量的值为OFF的话，我们也可以手动
调用ANALYZE TABLE语句来重新计算统计数据，比如我们可以这样更新关于
t_emp表的统计数据：

mysql> select * from mysql.innodb_table_stats where table_name='t_emp';
+---------------+------------+---------------------+--------+----------------------+--------------------------+
| database_name | table_name | last_update         | n_rows | clustered_index_size | sum_of_other_index_sizes |
+---------------+------------+---------------------+--------+----------------------+--------------------------+
| employees     | t_emp      | 2021-08-19 07:19:44 | 299645 |                  929 |                      578 |
+---------------+------------+---------------------+--------+----------------------+--------------------------+
1 row in set (0.00 sec)

mysql> analyze table employees.t_emp;
+-----------------+---------+----------+----------+
| Table           | Op      | Msg_type | Msg_text |
+-----------------+---------+----------+----------+
| employees.t_emp | analyze | status   | OK       |
+-----------------+---------+----------+----------+
1 row in set (0.05 sec)

mysql> select * from mysql.innodb_table_stats where table_name='t_emp';
+---------------+------------+---------------------+--------+----------------------+--------------------------+
| database_name | table_name | last_update         | n_rows | clustered_index_size | sum_of_other_index_sizes |
+---------------+------------+---------------------+--------+----------------------+--------------------------+
| employees     | t_emp      | 2021-08-30 08:48:24 | 299468 |                  929 |                      578 |
+---------------+------------+---------------------+--------+----------------------+--------------------------+
1 row in set (0.00 sec)

ANALYZE TABLE语句会立即重新计算统计数据，也就是这个过程是同步的，在表
中索引多或者采样页面特别多时这个过程可能会特别慢最好在业务不是很繁忙
的时候再运行。

手动更新innodb_table_stats和innodb_index_stats表

其实innodb_table_stats 和innodb_index_stats表就相当于一个普通的表一样，
我们能对它们做增删改查操作。这也就意味着我们可以手动更新某个表或者索引
的统计数据。比如说我们想把t_emp表关于行数的统计数据更改一下可以这
么做：

1. 更新innodb_table_stats 表。

2. 让MySQL 查询优化器重新加载我们更改过的数据。

更新完innodb_table_stats只是单纯的修改了一个表的数据，需要让MySQL
查询优化器重新加载我们更改过的数据，运行下边的命令就可以了：

FLUSH TABLE t_emp;

实验1：地理数据的统计处理

实验步骤与结果分析：

1.点击菜单栏【文件】下拉选项框，打开已经下载好的Excel表“"D:\桌面\计量地理学实习\表2-1某地区有关农业统计数据.xls"”，如下图所示：

2.点击菜单栏上面的【分析】—【描述统计】—【频率】工具，如下图所示：

​3.将需要进行统计分析的变量选中加载到右边，点击确定得到如下结果（每个变量因子的频数统计表）：

4.选中【分析】—【描述统计】—【描述】工具，将需要进行统计分析的变量选中加载到右边，如下图所示：

5.点击确定得到如下输出结果（每个变量的统计参数）：

​6.最后将其导出为柱状图，更加直观的查看各个变量之间的统计参数差别，导出图表如下图所示：

​

实验2：相关分析

实验步骤与结果分析

1.实验数据整理准备后加载到SPSS，如下图所示：

1. 在进行双变量相关分析前，我们需要对数据进行相关性检验，选中菜单栏【图形】|【回归变量图】

1. 将两个变量分别加载进来，如下图所示：

可以看到两者之间是属于负相关。

4.由于我们的相关分析是两个变量之间的分析，为此我们打开【分析】—【相关】—【双变量】工具，将两个变量【水土流失面积】和【土壤含氮量】加载进去，

5.从表中可以看到，水土流失面积和土壤含氮量存在相关关系，其相关系数为-0.946，呈现中度相关性，且在0.01的显著性水平上显著，即样本数据中的这个相关性在总体中一样有效。

实验3：主成分分析

实验步骤与结果分析：

1.数据准备，在SPSS载入“"D:\桌面\计量地理学实习\主成分分析.xlsx"”数据，如下图所示：

2.打开【分析】|【降维】|【因子分析】工具，将数据中除了【城市】这个变量，其余变量全部添加进去，

3.点击【描述】，勾选新打开界面的【系数】选项和【抽取】中的【碎石图】选项（使得分析结果更为直观），如下图所示：

1. 点击确定得到主成分分析运算结果。在公因子方差（Communalities）表中，给出了因子载荷阵的初始公因子方差（Initial）和提取公因子方差（Extraction）。

​总方差解释：

​

5.该表按顺序排列出主成分得分的方差（Total），在数值上=相关系数矩阵的各个特征根λ，因此可以直接根据特征根计算每一个主成分的方差百分比和方差累计值。由图可知，主成分是两个，都是方差（特征根）大于1的，第一主成分占比重62.602%，第二主成分占比重23.514%，这两个主成分达到85.116%，超过了85%，可以说用这两个指标评价各省份的经济可以近似代替原来的10个指标。主成分的数目可以根据相关系数矩阵的特征根来判定。相关系数矩阵的特征根刚好等于主成分的方差，而方差是变量数据蕴涵信息的重要判据之一。

​6.从碎石图看的话也可以知道由图直观的看出，成分1、2包含了大部分信息，从3开始就基本趋向平稳状态了。

7.该表是主成分载荷矩阵，每一列载荷值都显示了各个变量与有关主成分的相关系数。以第一列为例，0.69实际上是总人口与第一个主成分的相关系数。

8.事实上，有如下关系成立：相关系数矩阵的特征根＝方差贡献＝主成分得分的方差。两个主成分可以解释各个变量达到了最小72.9%，最大97%，如果我们将8个主成分全部提取，则主成分载荷的行平方和都等1，就是第一张表上面的起始公因子方差。到此可以明白：在Communalities中，Initial对应的是初始公因子方差，实际上是全部主成分的公因子方差，Extraction对应的是提取的主成分的公因子方差，我们提取了两个主成分，故计算公因子方差时只考虑两个主成分。

提取主成分的原则上要求公因子方差的各个数值尽可能接近，亦即要求它们的方差小，当公因子方差完全相等时，它们的方差为0，这就达到理想状态。实际应用中，只要公因子方差数值彼此不相差太远就行了。从上面给出的结果可以看出：提取两个主成分的时候，变量客运总量（万人）的公因子方差偏小，这暗示提取2个主成分，客运总量（万人）方面的信息可能有较多的损失。至于方差贡献，反映对应主成分的重要程度。

总结，决定主成分数目的3个原则：1.只取λ>1的特征根对应的主成分；2.累计百分比达到80%~85%以上的λ值对应的主成分；3.根据特征根变化的突变点决定主成分的数量；

9.接下来根据得到的特征值和主成分载荷值（需要复制到excel表中整理在SPSS打开）计算每一个变量的特征向量，打开【转换】|【计算变量】工具，在目标变量中输入新的名字，输入公式：V1（第一主成分的载荷值）/SQRT（第一主成分的特征值6.26），对于第二主成分计算其特征向量也是一样的操作。

10.两个主成分的特征向量计算结果：

将Ui与10个变量的标准化值相乘即可得到两个主成分Y1、Y2的表达式:

Y1=0.28*X1+0.06X2+0.24X3+0.34X4+0.19X5+0.38X6+0.36X7+0.38X8+0.38X9+0.38X10

Y2=0.42*X1-0.55X2+0.44X3-0.21X4+0.44X5-0.03X6-0.22X7-0.12X8-0.01X9-0.17X10

实验4：因子分析

实验步骤与结果分析：

1.数据准备，在SPSS载入“"D:\桌面\计量地理学实习\因子分析.xlsx"”数据。

2.打开【分析】|【降维】|【因子分析】工具，将数据中除了【城市】这个变量，其余变量全部添加进去，

3.分别点击【描述】、【抽取】和【旋转】中的相关选项，如下图所示：

4.从运行结果上可以看到KMO值为0.762，接近于1，说明这些数据适合进行因子分析。同时Bartlett球形度检验中的Sig值为0.000，小于显著水平0.05，说明变量之间存在相关关系，可以做因子分析。

公因子方差最小值为0.73，所有的变量都可以使用公因子进行表达。

这是旋转成份矩阵。

实验5：聚类分析

实验步骤与结果分析：

1.数据准备，在SPSS载入“"D:\桌面\计量地理学实习\聚类分析.xlsx"”数据。

2.打开【分析】|【分类】|【系统聚类】工具，将数据中所有的变量全部添加进去，并且设置相关选项的设置，具体如下图所示：

2.首先给出的是样品处理摘要（CaseProcessingSummary）。摘要告诉我们如下内容：有效样品的数目和百分比，缺失样品的数目和百分比，全部样品的数目和百分比。由于没有数据缺失，故全部21个样本参与聚类，有效样品为100%。

3.从进度表可以看出，第1阶段（Stage1），首先将第12号样品和第13号样品聚为一类，这两个样品的夹角余弦值最大，为623.445。

4.根据树形图，选择适当的尺度分为若干类。然后对分类结果进行分析，考察结果是否符合实际。

实验6：多元线性回归分析

实验步骤与结果分析：

1.数据准备，在SPSS载入“"D:\桌面\计量地理学实习\多元线性回归分析.xlsx"”数据。

1. 打开【分析】|【回归】|【线性】工具，将数据中所有的变量全部添加进去，并且设置相关选项的设置，具体如下图所示：

3.相关选项设置如下图所示：

将标准化残差“*ZRESID”选入“Y”中，将标准化预测值“*ZPRED”选入“X”中，勾选直方图和正态概率图，点击继续。

4.结果解读

由表可知DW值接近于2，自变量的自相关性不明显，模型设计得好，调整后的R方为0.99，模型拟合度非常好。

显著性表示自变量对因变量的影响程度，小于0.05表示于显著影响，越小影响越大，由表可以知道年降水量和年蒸发量对径流深度有显著影响。

VIF用于共线性诊断（变量之间的关联度），当0<VIF<10时，不存在多重共线性，由表可知年降水量和年蒸发量之间不存在多重共线性。

但是根据直方图可以知道直方图和正态曲线较为不吻合，说明残差不符合正态分布。

实验7：马尔可夫分析

实验步骤与结果分析：

1.时间序列数据整理后加载到Excel中，如下图所示：

​其中E1、E2和E3分别使用1、2和3代替，年份统一使用1-40代替，

2.为了计算状态的转移矩阵，我使用二维折线图直观显示3个状态随着年份之间的相互转变：

由图可知，

​从而得到初始转移矩阵

​3.2004年是E2状态，也就是2，预测2030年的农业收成，需要求出26步转移矩阵，为此我们需要计算初始转移矩阵的26次方，如下图所示：

​经过专业软件计算初始转移矩阵的26次方结果为：

4.由于2004年的状态向量为（7/13，2/13，4/13），也就是（0.538，0.154，0.308），求出26年后的状态向量：

计算结果为（0.365，0.353，0.282），为此可以知道在2030年的农业收成状态大概率是E1（很好）。