com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Table doesn’t exist解决方案

初次在mysql上出现这个问题，而window上的mysql没有出现这个问题。可想而知，因为myql是安装在linux上的，所以有大小写之分。所以查询表名时，注意表名的大小写，数据库里是小写的表名，就应该都小写。

外键

大批量数据操作时，做外键关联是十分消耗性能的，最好是在代码中逻辑关联，不要物理关联。

字段：text类型

https://zhuanlan.zhihu.com/p/280021373
一般很少用，如果需要记录大量的数据(TEXT类型最大存储长度2**16-1 = 65535 Bytes)可以将数据写到文件中，把文件地址存到该字段中就行，读取的时候根据文件地址获取文件再读取。如果每个字段都是很大的数据，那么范围查询io操作太频繁了。

Text改造建议

当我们的表中存在类似于 TEXT 或者是很大的 VARCHAR类型的大字段的时候，如果我们大部分访问这张表的时候都不需要这个字段，我们就该义无反顾的将其拆分到另外的独立表中，以减少常用数据所占用的存储空间。这样做的一个明显好处就是每个数据块中可以存储的数据条数可以大大增加，既减少物理 IO 次数，也能大大提高内存中的缓存命中率。

使用es存储

在MySQL中，一般log表会存储text类型保存request或response类的数据，用于接口调用失败时去手动排查问题，使用频繁的很低。可以考虑写入本地log file，通过filebeat抽取到es中，按天索引，根据数据保留策略进行清理。

使用对象存储

有些业务场景表用到TEXT，BLOB类型，存储的一些图片信息，比如商品的图片，更新频率比较低，可以考虑使用对象存储，例如阿里云的OSS，AWS的S3都可以，能够方便且高效的实现这类需求。

总结

由于MySQL是单进程多线程模型，一个SQL语句无法利用多个cpu core去执行，这也就决定了MySQL比较适合OLTP（特点：大量用户访问、逻辑读，索引扫描，返回少量数据，SQL简单）业务系统，同时要针对MySQL去制定一些建模规范和开发规范，尽量避免使用Text类型，它不但消耗大量的网络和IO带宽，同时在该表上的DML操作都会变得很慢。
另外建议将复杂的统计分析类的SQL，建议迁移到实时数仓OLAP中，例如目前使用比较多的clickhouse，里云的ADB，AWS的Redshift都可以，做到OLTP和OLAP类业务SQL分离，保证业务系统的稳定性。