一、由linux控制的系统，在硬件上做出相应的相应，如采集温度，实现linux的socket通信，就需要由内核进行控制，而内核就是通过用户输入的命令来进行执行相应的动作，而shell就是将我们输入的命令与内核进行通信。

查看linux可以使用的shell，在/etc/shells这个文件中。

/bin/csh
/bin/sh
/usr/bin/es
/usr/bin/ksh
/bin/ksh
/usr/bin/rc
/usr/bin/tcsh
/bin/tcsh
/usr/bin/esh
/bin/dash
/bin/bash
/bin/rbash
/usr/bin/screen

为什么我们系统上合法的shell要写入etc/shells，因为系统某些服务在运行的过程中，就会去检查用户能够使用的shell，而shell的查询就是通过etc/shells这个文件。

二、bash shell的功能

1、命令记忆功能

在命令行中按上下键就可以找到前后输入的命令。这些命令都存放在.bash_history中。需要注意的是，

~./bash_history 记录的是前一次登陆所执行的命令，而这一次所执行的命令都被存放在内存中，当成功注销掉系统后，该命令就会写入.bash_history.

2、命令与文件的补全功能

使用Tab键

3、命令别名的设置

像ls等都是系统定义的命令，我们也可以自己定义命令，通过使用alias即可。

4、通配符（Wildcard）

bash支持通配符来帮助用户进行查询和命令的执行。例如像知道/usr/bin下面有多少以l开头的文件，可以使用命令ls -l /usr/bin/l*

三、内置命令

内置 命令指命令内置在bash中。查看是否是内置命令可以使用type。当然查看文件的类型可以使用file命令。

四、变量

1、变量和变量的内容以"="进行连接

 myname=rongdeguo

2、等号两边不能有空格符。

     3、变量只能是英文字母与数字，但是开头不能是数字。

4、变量的内容若有空格，可以使用单引号或者双引号将变量的内容结合起来。但是双引号的特殊字符如$还保持原来的特性，单引号字符则是一般的字符（纯文本）

5、使用转义字符将特殊变量编程一般的字符。

五、export变量将自定义变量转换成环境变量

环境变量=全局变量

自定义变量=局部变量

一、问题

先思考个常见的问题：如何根据自己所在位置查询来查询附近50米的POI（point of interest，比如商家、景点等）呢（图1a）？

每个POI都有经纬度信息，我用图1b的SQL语句在mySQL中建立了POI_spatial的表，其中lat和lng两个字段来代表纬度和经度。为后续分析方便起见，我人造了40万个POI数据。

二、传统的解决思路

方法一：暴力方法

该方法的思路很直接：计算位置与所有POI的距离，并保留距离小于50米的POI。

插句题外话，计算经纬度之间的距离不能像求欧式距离那样平方开根号，因为地球是个不规整的球体（图2a），按最简单的完美球体假设，两点之间的距离函数应该如图2b所示。

该方法的复杂度为：40万*距离函数。我们将球体距离函数写为mysql存储过程distance，之后我们执行查询操作（图3），发现花费了4.66秒。

该方法耗时的原因显而易见，执行了40万次复杂的距离计算函数。

方法二：矩形过滤方法

该方法分为两部：

a）先用矩形框过滤（图4a），判断一个点在矩形框内很简单，只要进行两次判断（LtMin<lat<LtMax; LnMin<lng<LnMax），落在矩形框内的POI个数为n（n<<40万）；

b）用球面距离公式计算位置与矩形框内n个POI的距离（图4b），并保留距离小于50米的POI

矩形过滤方法的复杂度为：40万*矩形过滤函数 + n*距离函数（n<<40万）。

根据这个思路我们执行SQl查询（图5）（注： 经度或纬度每隔0.001度，距离相差约100米，由此推算出矩形左下角和右上角坐标），发现过滤后正好剩下两个POI。

此查询花费了0.36秒，相比于方法一查询时间大大降低，但是对于一次查询来说还是很长。时间长的原因在于遍历了40万次。

方法三：B树对经度或纬度建立索引

方法二耗时的原因在于执行了遍历操作，为了不进行遍历，我们自然想到了索引。我们对纬度进行了B树索引。

此方法包括三个步骤：

a）通过B树快速找到某纬度范围的POI（图6a），个数为m（m<40万），复杂度为Log(40万)*过滤函数;

b）在步骤a过滤得到的m个POI中查找某经度范围的POI（图6b），个数为n(n<m)，复杂度为m*过滤函数；

c） 用球面距离公式计算位置与步骤b得到的n个POI的距离（图6c），并保留距离小于50米的POI

执行SQL查询（图7），发现时间已经大大降低，从方法2的0.36秒下降到0.01秒。

三、B树能索引空间数据吗？

这时候有人会说了：“方法三效果如此好，能够满足我们附近POI查询问题啊，看来B树用来索引空间数据也是可以的嘛！”

那么B树真的能够索引空间数据吗？

1）只能对经度或纬度索引（一维索引），与期望的不符

我们期待的是快速找出落在某一空间范围的POI（如矩形）（图8a），而不是快速找出落在某纬度或经度范围的POI（图8b），想象一下，我要查询北京某区的POI，但是B树索引不仅给我找出了北京的，还有与北京同一维度的天津、大同、甚至国外城市的POI，当数据量很大时，效率很低。

2）当数据是多维，比如三维（x，y，z），B树怎么索引？

比如z可能是高程值，也可能是时间。有人会说B树其实可以对多个字段进行索引，但这时需要指定优先级，形成一个组合字段，而空间数据在各个维度方向上不存在优先级，我们不能说纬度比经度更重要，也不能说纬度比高程更重要。

3）当空间数据不是点，而是线（道路、地铁、河流等），面（行政区边界、建筑物等），B树怎么索引？

对于面来说，它由一系列首尾相连的经纬度坐标点组成，一个面可能有成百上千个坐标，这时数据库怎么存储，B树怎么索引，这些都是问题。

既然传统的索引不能很好的索引空间数据，我们自然需要一种方法能对空间数据进行索引，即空间索引。

下节将对空间索引分类体系、原理、优缺点及数据库支持情况进行阐述。