基于地理位置的查询；
朝外soho 39.920086,116.454182
查询距离朝外soho 5km范围内的
上面query是查询条件
下面post_filter对查询结果过滤，按照地理位置过滤/

GET twitter/_search
{
  "query":{
    "bool":{
      "must":[
        {
          "match":{
            "address":"北京"
          }
        }
      ]
    }
  },
  "post_filter": {
    "geo_distance": {
      "distance": "5km",
      "location": {
        "lat": 39.920086,
        "lon": 116.454182
      }
    }
  }
}

查询距离朝外soho 5km范围内的 按距离排序/

GET twitter/_search
{
  "query":{
    "bool":{
      "must":[
        {
          "match":{
            "address":"北京"
          }
        }
      ]
    }
  },
  "post_filter": {
    "geo_distance": {
      "distance": "5km",
      "location": {
        "lat": 39.920086,
        "lon": 116.454182
      }
    }
  },
  "sort": [
    {
      "_geo_distance": {
        "location": {
          "lat": 39.920086,
          "lon": 116.454182
        }, 
        "order": "asc",
        "unit": "km"
      }
    }
  ]
}

1、B+树查询速度更稳定：B+所有关键字数据地址都存在叶子节点上，所以每次查找的次数都相同所以查询速度要比B树更稳定。（树高度扁平层级少，数据均在叶子节点上）

2、B+树天然具备排序功能：B+树所有的叶子节点数据构成了一个有序链表，在查询大小区间的数据时候更方便，数据紧密性很高，缓存的命中率也会比B树高。（B+树天然有序）

3、B+树全节点遍历更快：B+树遍历整棵树只需要遍历所有的叶子节点即可，而不需要像B树一样需要对每一层进行遍历，这有利于数据库做全表扫描。（每个叶子节点，均指向下一个叶子节点）

在数据插入时，需要维护B+树，推荐使用递增字段作为主键，否则会增加写入开销。

节点的度：一个节点拥有的子树数

叶子节点：度为0的节点

属性	说明
name=value	键值对，可以设置要保存的 Key/Value
Domain	域名，默认是当前域名
maxAge	最大失效时间(毫秒),设置在多少后失效
secure	当 secure 值为 true 时，cookie 在 HTTP 中是无效，在 HTTPS 中才有效
Path	表示 cookie 影响到的路，如 path=/。如果路径不能匹配时，浏览器则不发送这个Cookie
Expires	过期时间(秒)，在设置的某个时间点后该 Cookie 就会失效，如 expires=Money, 05-Dec-11 11:11:11 GMT
httpOnly	如果在COOKIE中设置了 httpOnly 属性，则通过程序(JS脚本)将无法读取到COOKIE信息，防止XSS攻击产生

互联网公司，几乎不使用存储过程。

而银行、金融等国企则喜欢存储过程。

不使用存储过程

互联网行业，一般都会考虑到并发问题，存储过程在高并发场景下数据库往往是性能瓶颈

如果要换库，则存储过程要重写。

没有办法断点，下层数据结构只是稍微变动，根本无法找到出错点，只是提示一下说：ERROR:1064啥的。

存储过程只是单机时代的产物，并不适合互联网时代。互联网公司几乎不使用存储过程，阿里则明确禁止使用存储过程。

MySQL/PostgreSQL对存储过程支持比较弱，没有实现Oracle的SQL compilation。而互联网公司几乎都不太可能使用 Oracle ，它的价格一般都承受不起。

支持集群的存储过程，太少，一般情况下要分库，此时存储过程就无法支持。

使用存储过程

开发速度快，如果业务更新频繁。即使是请10个开发人员，也比不过一个写存储过程，后者只需要写几条sql，写业务代码则需要非常多。

性能更优，如果钱不是问题，已经使用了oracle、SQLServer，使用存储过程来优化性能，未必不好。

责任分明，谁提供数据库，出问题责任就在谁身上，只管写就是了。（各个部门责任不一样，不一定非要站在总体的角度来看）

对于银行项目，数据往往保留很长时间，无论是新数据还是旧数据处理，定时处理等，一个超大型的数据库，不使用存储过程，几乎是无力管理。

MySQL锁表一般发生在insert update delete，那select操作会缩表吗，不同的引擎是否表现一样呢？

会锁表，但分情况，一般是加S锁，如果是有索引，会给行锁，如果没有索引，则给的是表锁。

S锁不会影响到其他的查询，但是会影响到插入和更新，也就是说，如果你有一个查询很慢，且进行了表锁，你的插入和更新都会被影响到，但不会影响其他的查询，但如果有索引，走的行锁，又不会影响到其他的插入和更新。

多表查询，并且全表扫描时，就更容易出现耗时几十秒的sql，对于sql要合理的增加索引。

从速度上看，网络<磁盘<内存<CPU ，多次sql查询，网络开销是很大的。

要考虑单表查询，首先 service 服务器 和 db服务器网络延迟不能太大。

在实际开发中，我们不可避免的要关联几张数据表来合成最终的展示数据，如：

select * from tag
join tag_post on tag_post.tag_id=tag.id
join post on tag_post.post_id=post.id
where tag.tag='mysql';

同样的，我们可以用以下查询来代替：

select * from tag where tag='mysql';

select * from tag_post where tag_id=1234;

select * from post where id in(123,456,567,9989,8909);

看似后者查询步骤更多了，原本一个方法查询就能出结果，现在直接变成三个。但是这样做的好处是：

• 更方便阅读，不会一次有很长的sql，每个小步骤划分逻辑也更清晰
• 代码可复用，join联表的SQL，基本不太可能被复用，但是拆分后的单表查询，如果功能相同则可以复用
• 提高数据库效率，如果一次连表查询太大，数据库崩溃不说，多表会导致同时锁住多张表，这样性能低。
• 缓存利用率更高，单次查询，如果数据不经常变化，则可以缓存下来，连表则几乎不行

有的情况下，不适合多次查询，比如：

• 分开查询的数据庞大，有的时候必须依赖于数据库的连表筛选条件，以过滤更少的数据
• 分页问题，如果多次查询的结构不合理，则导致分页错乱。
• 网络问题，如果分开查询每次网络延迟太大，则导致更加缓慢

综上，对系统质量要求较高，比如考虑到以后的分库分表、代码重用、结果缓存等，那么：优先考虑分开查询，如果某个具体问题确实不适合多次查询，则考虑 join。

分开查询，是重业务、轻db的思想，能降低数据库耦合。

inner join内连接，两边条件同时满足，相当于 &&

left join 左外连接，左边必须满足（右边不满足时自动补NULL）

right join 右外连接，右边必须满足 （左边不满足时自动补NULL）

full join 满外连接，左边和右边，满足任意一个，相当于 ||

C2C是电子商务的专业用语，意思是个人与个人之间的电子商务，其中C指的是消费者，因为消费者的英文单词是Customer（Consumer），所以简写为C，又因为英文中的2的发音同to，所以C to C简写为C2C，C2C即 Customer（Consumer） to Customer（Consumer）。 比如一个消费者有一台电脑，通过网络进行交易，把它出售给另外一个消费者，此种交易类型就称为C2C电子商务。

网上有不少C2C网站，其购物方式都大同小异，淘宝网的购物流程介绍（如下）：

搜索

首先第一步是搜索。搜索有以下几种方法：第一招：明确搜索词您只需要在搜索框中输入要搜索的宝贝店铺掌柜名称，然后点击“回车”，或单击“搜索”按钮即可得到相关资料。第二招：用好分类不知道您是否注意到，许多搜索框的后面都有下拉菜单，有宝贝的分类、限定的时间等等选项，用鼠标轻轻一点，就不会混淆分类了。比如：您搜索“火柴盒”，会发现有很多汽车模型，原来它们都是“火柴盒”牌的。当您搜索时选择了“居家日用”分类，就会发现真正色彩斑斓的火柴盒在这里。第三招：妙用空格想用多个词语搜索？在词语间加上空格，就这么简单！第四招：精确搜索（1） 使用双引号：比如搜索“佳能相机”，它只会返回网页中有“佳能相机”这四个字连在一起的商品，而不会返回诸如“佳能IXUSI5专用数码相机包”之类的商品。（注：此处引号为英文的引号）（2） 使用加减号：在两个词语间用加号，意味着准确搜索包含着这两个词的内容；相反，使用减号，意味着避免搜索减号后面的那个词。第五招：不必担心大小写淘宝的搜索功能不区分英文字母大小写。无论您输入大写还是小写字母都可以得到相同的搜索结果。输入“nike”，或“NIKE”，结果都是一样的，因此你可以放心搜索。

联系卖家

第二步，找到宝贝了，那就该联系卖家了：请您在看到感兴趣的宝贝时，先和卖家取得联络，多了解宝贝的细节，询问是否有货等等。多沟通能增进您和卖家的了解，避免很多误会。第一招：发站内信件给卖家站内信件是只有您和卖家能看到的，相当于某些论坛里的短消息。您可以询问卖家关于宝贝的细节、数量等问题，也可以试探地询问是否能有折扣。第二招：给卖家留言每件宝贝的下方都有一个空白框，在这里写上您要问卖家的问题。请注意，只有卖家回复后这条留言和答复才能显示出来。因为这里显示的信息所有人都能看到，建议您不要在这里公开自己的手机号码、邮寄地址等私人信息。第三招：利用聊天工具不同网站支持不同的聊天工具，淘宝是旺旺，拍拍是QQ，利用它们尽量直接找到卖家进行沟通。

购买

第三步，当你和卖家达成共识后，那就购买吧！

评价

最后一步是评价：当您拿到商品之后，可以对卖家做确认收货以及对卖家的服务做出评价。这是您的权力哦！ 如果对商品很不满意，可以申请退货，或者是换货，细节方面请与卖家联系。网购的流程大致如上。

主要区别

B2B：企业间的EC

B2C：企业对个人用户的EC

C2C：个人对个人的EC

C2B：个人对商家的EC

M2C：厂家对个人的EC

I2C：信息提供对消费者的

EC注：EC是指电子商务

电子商务之失败

因素个人资料的外泄是最大的因素，如果有黑客破解网页源代码，并在网页上种下木马或是病毒，只要你登入并打上个人资料，黑客便可以马上知道你在网页上打下哪些个人资料。所以如何保护顾客的个人资料等是电子商务最大的问题，如果不妥善处理，那么电子店家便会被淘汰。

ctrl+shift+[是折叠

ctrl+k ctrl+0 是折叠全部

ctrl+shift+]是展开

ctrl+k ctrl+j 是展开全部

这些快捷键都很费劲。

MySQL 5.7 

最大接收默认值为 4M=4194304=4*1024*1024，由系统变量max_allowed_packet 控制。

 show global variables like 'max_allowed_packet';

SQL 长度超过这个值，执行会发生什么呢？

SQL 错误 [S1000]: Packet for query is too large (4,202,590 > 4,194,304).
 You can change this value on the server by setting the 'max_allowed_packet' variable.

从以上结果可以看出，查询SQL 太长，MySQL API 返回了异常，提示query 超过了max_allowed_packet 允许的最大值。

  max_allowed_packet 最大值为1G，最小值为1K，默认值为4M，值为1024的倍数。

MySQL 8.0 开始，默认值已经增大到了64M；但最大值还是1G，最小值是1K，值仍是1024的倍数 ，没有改变。

修改方法

1、修改配置文件

可以编辑my.cnf来修改（windows下my.ini）,在[mysqld]段或者mysql的server配置段进行修改。

代码如下:
max_allowed_packet = 20M
 
如果找不到my.cnf可以通过
代码如下:
mysql --help | grep my.cnf

去寻找my.cnf文件。
linux下该文件在/etc/下。

2、在mysql命令行中修改

在mysql 命令行中运行:

代码如下:

set global max_allowed_packet = 2*1024*1024*10
注意：
这样修改会报错（不能识别单位）：mysql> set  max_allowed_packet=16MB;
ERROR 1232 (42000): Incorrect argument type to variable 'max_allowed_packet'

然后退出命令行，重启mysql服务，再进入。
mysql重启命令：

1、使用 service 启动：service mysqld restart
2、使用 mysqld 脚本启动：/etc/inint.d/mysqld restart

代码如下:

show VARIABLES like '%max_allowed_packet%';

查看下max_allowed_packet是否编辑成功
注意：该值设置过小将导致单个记录超过限制后写入数据库失败，且后续记录写入也将失败。