Sharding-Proxy查询分库分表数据，很方便！！

##背景
目前公司不大，没有方便的数据库平台支持分库分表数据的查询，每次只能拿到分表的数据字段，手动hash获得标的索引，再去物理表查询，费时费力

##改造
目前市面上有很多mysql分库分表的代理，自己选择了Sharding-proxy

我用的docker，用的Sharding-proxy版本4.1.0，没有用太高的，太高的试了一次，一直有问题，mysql客户端连不上(navicat 15不行，后来换了mysql WorkBench)

##流程
1、下载Sharding-proxy
使用docker下载

docker pull apache/sharding-proxy:4.1.0

下载好后，自己本地创建目录与docker目录对应，然后启动，对外端口用13408

docker run --name=sharding_proxy_4_1_0 -d -v /Users/kang/sharding_proxy4.1.0/conf:/opt/sharding-proxy4.1.0/conf -v /Users/kang/sharding_proxy4.1.0/ext-lib:/opt/sharding-proxy4.1.0/ext-lib --env PORT=3408 -p13408:3408 apache/sharding-proxy:4.1.0

mysql需要下载jar包，放到ext-lib目录下，conf文件下，创建config-sharding.yaml和server.yaml

其中config-sharding.yaml是物理表与逻辑表的对应关系，server.yaml是登录sharding-proxy的用户信息
config-sharding.yaml 可参考官网配置(https://shardingsphere.apache.org/document/legacy/3.x/document/cn/manual/sharding-proxy/configuration/) 这里我只写了需要的

schemaName: sharding_db

dataSources:
  tracking_sharding:  //数据库别名
    url: jdbc:mysql://自己的数据库地址
    username: ****
    password: *****
    connectionTimeoutMilliseconds: 60000
    idleTimeoutMilliseconds: 60000
    maxLifetimeMilliseconds: 1800000
    maxPoolSize: 65

shardingRule:
  tables:
    logistics_track_info: //逻辑表
      actualDataNodes: tracking_sharding.logistics_track_info_${0..511} //物理表 512个表
      tableStrategy: 
        inline:
          shardingColumn: logistics_number
          algorithmExpression: logistics_track_info_${logistics_number % 512}
  bindingTables:
    - logistics_track_info,logistics_track_relation
  defaultTableStrategy:
    none:

server.yaml

authentication:
  users:
    root: //可访问所有表
      password: root
    sharding:  //只能访问sharding
      password: sharding
      authorizedSchemas: sharding_db

启动之后，查看docker日志，没有报错，最后提示加载了逻辑表和所有物理表，就是成功的

然后用mysql workbench链接

启动后，直接连会有这个报错，一直连不上

Lost connection to MySQL server at 'reading initial communication packet', system error: 0

等个十几分钟，再练就可以了(有时候就是连不上，我就重启sharding-proxy，搞几次就可以)，，具体原因不清楚，可能docker不稳定，导致连不上

总结
1、每次重启，都会连不上，很奇怪，多次重启，多尝试就可以
2、我的分表有500多，导致30s查询超时，加大这个值