1，

在数据库中，现在都是指定为utf8来存储。当varchar中存储的是非英文字符串，对其进行order by排序的时候非常的慢（比英文字符串起码慢10倍），group by对字符串进行分组的话，英文和非英文的性能也是一样快的，当时还以为数据库有啥问题，研究的半天都没啥结论。总觉得，如果字符串是按照字节流来比较排序的话，英文和非英文的应该是一样的性能才是。再后来猜测一定是非英文的时候不是按照字节流的顺序来排序的。为了按照字节流，强制把字符串转成bytea类型，然后进行order by，发现果然英文非英文排序一样快了。

看来，utf8的字符串果然不是按照字节流的顺序来排序的，具体按啥，我也不知道了。总之，如果你对非英文的字符串排序结果没啥特别要求，只需要有个固定的顺序的话，把utf8转换成bytea后，再进行排序就会很快了。

2，

postgis有2个函数用于把geometry合并，一个st_union,一个st_collect。2个函数都是把多个geometry合并成一个geometry。

st_union会对geomtry进行检查，如果合并的geometry有重复的geometry，好像会报错，直接导致数据库连接断开。不过有时候也不会出错。到底啥原因我也不清楚。感觉如果geometry中有相同的geometry，还是少用st_union。同时st_union的性能比st_collect要慢很多。

st_collect只是把所有的geometry简单的合并成一个mulit-geo，这个函数速度会快很多，如果没啥特别的需求，还是用st_collect，并且从来没有导致数据库连接断开的情况

3,

如果有3个以上的table通过《字符串相等》进行join，前2个表会用merger join或者hash join，第3个以后的表总是采用nest loop，导致性能非常的慢。特别是table的数据量不是特别大。后来，通过 setenable_nestloop = false才把执行计划改变过来。