1.2017-10-23：关于jar包执行：当jar包里有main函数，在控制台，进入jar包当前目录，输入java -jar test.jar，即可执行jar包的mian函数
2.2017-10-23：关于Java文件运行：一个Java文件，一个类，一个mian函数，在控制的先 Javac test.java 编译Java文件，再 java test 执行Java.class文件
3.2017-10-23：关于bat文件：用bat文件执行Java.jar，test.bat java -jar "C:UsersDesktop est.jar"
4.2017-10-24:关于表字段：能搞关联查询到的字段就尽量不冗余，除非有冗余的必要
5.2017-10-24：关于更新非常频繁，但用的非常非常少的字段, 如果这个字段的结果不是必须维护，可以通过简单的SQL语句查询得到，就不维护，相反，如果用的非常频繁，那么肯定是要维护的，-------出发点都是提升系统性能
6.2017-10-25:关于复用很强的数据：复用性强的抽出来，尽可能减少执行次数
7.2017-10-25：关于业务数据（大批量）：能一次查出来，就一次查出来，不在for训练内再去分很多次去查相关的业务数据
8.2017-10-26:关于除（/）和模（%）：除取商，模取余，其实都是用一个数除以另一个数，运算过程一模一样，只是最终取得值不一样
9.2017-10-26：关于表：一张表就是一个实体模型，尽量不要参合其他实体，不然这张表会很乱，很多字段都是没有意义的
10.关于list嵌套list数据组装：要么for循环查询数据库，要把需要的数据全部拉出来，自己for循环处理组装数据
11.2017-10-30：关于开发中改表结构：那么久意味着返工
12.2017-11-02：关于数据维护和性能：要么就不维护，一旦维护了这条数据，就不怕就多维护几个字段
13.2017-11-03:关于代码独立，复用：相识点越多，用到的越多，越促使我们将这段代码，抽离，独立开来，这样清晰，独立，复用性强，方便维护
14.2017-11-03:关于表关联：如果关联关系是一条线，那么可以关联线中的任何一点都能回推（可以跳过上级，关联上上级），但如果是网络关联关系，一旦关联上上级，
你就再也找不到它的上级，有些功能刚开始简单，线性关系就够用，但后来需要用到网络关联，之前的数据就都有问题
15.2017-11-06:关于规范：不管是在什么地方，什么方面，有多个人在做同一件事的时候，就必需要有一个约定的规范，不然他一套，你一套东西，最后会乱死
16.2017-11-10:关于spring框架，对象绑定，如果属性绑定失败，spring框架不会抛任何异常，现在就是后台没有任何反应，跟没有掉到后台一样
17.2017-11-15:关于
class.getClassLoader()，class类装载器，首先类必须能够被装载（即在class的路径下）
17.2017-11-17:关于HTML上传图片，网页有选择图片的标签，浏览器在读取路径的时候发现是文件，会自动下载流
18. 关于switch case ： case中的值只能是常量，因为C语言中的 switch 不是 if 的替代品 编译时会对 switch 进行优化
根据 case 标签后面的常量值，生成跳转表，只经过少数次数的比较，就可以跳到对应标签下面。所以，标签也是不能重复的。如果允许变量，switch 只能退化成跟一连串的 if else, 对于一个数据也只能从头到尾地进行比较，也就失去了 switch 的意义。跳转表和逐个比较，这两种方式的复杂度差很多 这也是 python 没有引入和 C 语言里面的 switch case 相对应的控制结构的一个原因
19:关于关联查询：筛选条件加在on后面，和where 后面的区别， 加在on后面筛选的是 关联的数据 ，加在where后面 筛选的是查询结果数据，如果加在on后面，会造成能查出数据，但关联数据全部是空的情况
20:关于SQL替换字符串：方式一：select insert(mobile, 4, 4, 'XXXX') from sys_users ;方式二：select REPLACE(mobile, SUBSTR(mobile,4,4), 'XXXX') from sys_users
21.关于需求：确定的需求一定要记录下来，并且要把出发点，思路，等记下来（复杂的业务，重要的），不然下次再看肯定一脸懵逼，再次申明，重要，复杂的业务，思路一定要
具体，一步一步的明确记下来，不然等着重新花时间理吧
22：关于功能估测：出发点不同，别人要的完全OK的功能，我们想的是功能能用
23: 关于表字段关联设计：首先你得想清楚他们的关联关系是什么，再设计表结构
24: 关于方法声明，private,类私有的方法，如果针对于方法做引用，会出现类中引用对象全部是空的现象，没办法初始化
25: 关于文档，描述：复杂，生疏的东西一定得有文档记录，一定
26:关于解释：你跟别人解释的东西，或者定义的东西，一定要是对的，不然别人做出来之后，你就等着蛋疼吧
27:关于想法：真的是步步都是坑啊，想的总是不全，总是这样，什么情况啊，总是漏掉一些方面，代码写的太脆弱了
28:关于规则：确定的规则就不要轻易改，即使不合理，要改就必须全部改，改彻底，不然不一致，就是在埋雷
29.关于redis安装:1.redis-server --service-install redis.windows.conf 安装成windows 服务，2. redis-server --service-start 启动Widndows redis 服务3.redis-server --service-stop
停止服务 4. redis-server --service-install –service-name redisService1 –port 10001 安装多个redis 服务 5 redis-server --service-uninstall 卸载 Widndows redis 服务
30.关于mysql 视图：1.创建 create view name(想要创建的视图名称) as sql（视图执行的SQL） 2 删除 drop view if exists name(想要删除的视图名称);
31.关于资金流水：流水的意义在于，真实的动态流向，不能凭空增加，也不能凭空蒸发，每一次交易（流动），来自哪里，去向哪里，必须有迹可循
意义：水的流动的意义，在于运输，交互，营养，资源，生命 ，水的意义，是因为它的特性，赋予流动，也因为流动，赋予它意义
资金流动的意义，在于运输，交互，价值，资源，创造 ，资金的意义，因为它的特性，赋予流动，也因为流动，赋予它意义
它们的本质，只有伴随 流动，才能体现它们的意义，实现它们该有的价值，也才能产生增值
32.关于查询结果区域 查询表：在select 和 from 之间的 结果区域，可以嵌套使用 查询语句（select from）查询想要的结果
33.关于版本控制：重要的业务逻辑，一定要考虑版本的问题，你的代码被调用的场景，不可控，你必须得控制在任何场景下的调用都不会有问题，如网络延迟，重复点击
34.关于校验：代码校验状态只能防止正常场景的业务问题，数据版本校验和数据状态校验，双重校验才足以保证，校验的正确性
35.关于批量插入：insert into 表名 (字段名,字段名,....) select 字段名,字段名,...from ()