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的数据量不是特别大。后来,通过 set enable_nestloop = false才把执行计划改变过来。