DailyNote

source  ： @Param注解的用法解析 - 苍青浪 - 博客园 (cnblogs.com)

      1.实例一 @Param注解单一属性

dao层示例   Public User selectUser(@param(“userName”) String name,@param(“userpassword”) String password);

xml 映射对应示例

 
   select  *  from user_user_t   where user_name = #{userName，jdbcType=VARCHAR} and user_password=#{userPassword,jdbcType=VARCHAR} 
 
注意：采用 #{} 的方式把 @Param注解 括号内的参数进行引用（括号内参数对应的是形参如 userName对应的是name）；
 
        2. @Param注解JavaBean对象
 
dao层示例      public List getUserInformation(@Param("user") User user);
 
xml映射对应示例
 
 
        select  
         
        from mo_user t where 1=1 
                       
               and   t.user_name = #{user.userName}   
               and   t.user_age = #{user.userAge}   
     

         3. 使用@Param注解

当以下面的方式进行写SQL语句时：

@Select("select column from table where userid = #{userid} ")    

    public int selectColumn(int userid);

当你使用了使用@Param注解来声明参数时，如果使用 #{} 或 ${} 的方式都可以。

@Select("select column from table where userid = ${userid} ")

    public int selectColumn(@Param("userid") int userid);

当你不使用@Param注解来声明参数时，必须使用使用 #{}方式。如果使用 ${} 的方式，会报错。

@Select("select column from table where userid = ${userid} ")

    public int selectColumn(@Param("userid") int userid);

     4. 不使用@Param注解 ： 

不使用@Param注解时，参数只能有一个，并且是Javabean。传递的是对象，在SQL语句里可以引用JavaBean的属性，而且只能引用JavaBean的属性。

source ： SQL注入详解 - myseries - 博客园 (cnblogs.com)

1. 什么是sql注入：SQL注入是比较常见的网络攻击方式之一，它不是利用操作系统的BUG来实现攻击，是针对程序员编写时的疏忽，通过SQL语句，实现无账号登录，甚至篡改数据库。

2. Sql 注入带来的威胁主要有如下几点

• 猜解后台数据库，这是利用最多的方式，盗取网站的敏感信息。
• 绕过认证，列如绕过验证登录网站后台。
• 注入可以借助数据库的存储过程进行提权等操作

2. SQL注入攻击的总体思路　

　　1：寻找到SQL注入的位置

　　2：判断服务器类型和后台数据库类型

　　3：针对不同的服务器和数据库特点进行SQL注入攻击

3. 如何防御SQL注入

　　注意：但凡有SQL注入漏洞的程序，都是因为程序要接受来自客户端用户输入的变量或URL传递的参数，并且这个变量或参数是组成SQL语句的一部分，对于用户输入的内容或传递的参数，我们应该要时刻保持警惕，这是安全领域里的「外部数据不可信任」的原则，所以要从变量的检测、过滤、验证下手，确保变量是开发者所预想的。

        （1）检查变量数据类型和格式

　　只要是有固定格式的变量，在SQL语句执行前，应该严格按照固定格式去检查，确保变量是我们预想的格式，这样很大程度上可以避免SQL注入攻击。

        比如，我们前面接受username参数例子中，我们的产品设计应该是在用户注册的一开始，就有一个用户名的规则，比如5-20个字符，只能由大小写字母、数字以及一些安全的符号组成，不包含特殊字符。此时我们应该有一个check_username的函数来进行统一的检查。不过，仍然有很多例外情况并不能应用到这一准则，比如文章发布系统，评论系统等必须要允许用户提交任意字符串的场景，这就需要采用过滤等其他方案了。

　　（2）过滤特殊符号

　　对于无法确定 固定格式的变量，一定要进行特殊符号过滤或转义处理。

       （3）绑定变量，使用预编译语句　　

        预编译语句的优势在于归纳为：一次编译、多次运行，省去了解析优化等过程；此外预编译语句能防止sql注入。

　　MySQL的mysqli驱动提供了预编译语句的支持，不同的程序语言，都分别有使用预编译语句的方法。实际上，绑定变量使用预编译语句是预防SQL注入的最佳方式，使用预编译的SQL语句语义不会发生改变，在SQL语句中，变量用问号?表示，黑客即使本事再大，也无法改变SQL语句的结构

        所谓预编译语句就是将这类语句中的值用占位符替代，可以视为将sql语句模板化或者说参数化。一般称这类语句叫Prepared Statements或者Parameterized Statements。

        Prepared Statements原理 是采用了预编译的方法，先将SQL语句中可被客户端控制的参数集进行编译，生成对应的临时变量集，再使用对应的设置方法，为临时变量集里面的元素进行赋值，赋值函数setString()，会对传入的参数进行强制类型检查和安全检查，所以就避免了SQL注入的产生。

        为什么Statement会被sql注入？  因为Statement之所以会被sql注入是因为SQL语句结构发生了变化。

"select*from tablename where username='"+uesrname+  

"'and password='"+password+"'"

在用户输入'or true or'之后sql语句结构改变。

select*from tablename where username=''or true or'' and password=''
这样本来是判断用户名和密码都匹配时才会计数，但是经过改变后变成了或的逻辑关系，不管用户名和密码是否匹配该式的返回值永远为true;

（2）为什么Preparement可以防止SQL注入。

　　因为Preparement样式为 select * from tablename where username=? and password=?

　　该SQL语句会在得到用户的输入之前先用数据库进行预编译，这样的话不管用户输入什么用户名和密码的判断始终都是并的逻辑关系，防止了SQL注入。

　　简单总结，参数化能防注入的原因在于，语句是语句，参数是参数，参数的值并不是语句的一部分，数据库只按语句的语义跑，至于跑的时候是带一个普通背包还是一个怪物，不会影响行进路线，无非跑的快点与慢点的区别。

4.#{} 或 ${} 

　    1、#将传入的数据都当成一个字符串，会对自动传入的数据加一个双引号。
如：where username=#{username}，如果传入的值是111,那么解析成sql时的值为where username="111", 如果传入的值是id，则解析成的sql为where username="id".　
　　2、$将传入的数据直接显示生成在sql中。
如：where username=${username}，如果传入的值是111,那么解析成sql时的值为where username=111；
如果传入的值是;drop table user;，则解析成的sql为：select id, username, password, role from user where username=;drop table user;

        3、# 方式能够很大程度防止sql注入，$ 方式无法防止Sql注入。
　　4、$方式一般用于传入数据库对象，例如传入表名.
　　5、一般能用#的就别用$，若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止sql注入攻击。
　　6、在MyBatis中，“${xxx}”这样格式的参数会直接参与SQL编译，从而不能避免注入攻击。但涉及到动态表名和列名时，只能使用“${xxx}”这样的参数格式。所以，这样的参数需要我们在代码中手工进行处理来防止注入。
【结论】在编写MyBatis的映射语句时，尽量采用“#{xxx}”这样的格式。若不得不使用“${xxx}”这样的参数，要手工地做好过滤工作，来防止SQL注入攻击。

5. mybatis是如何防止SQL注入的？

        MyBatis框架是半自动化的持久层框架，其SQL语句都要我们自己手动编写，这个时候当然需要防止SQL注入。其实，MyBatis的SQL是一个具有“输入+输出”的功能，类似于函数的结构，参考上面的两个例子。其中，parameterType表示了输入的参数类型，resultType表示了输出的参数类型。回应上文，如果我们想防止SQL注入，理所当然地要在输入参数上下功夫。上面代码中使用#的即输入参数在SQL中拼接的部分，传入参数后，打印出执行的SQL语句，会看到SQL是这样的：

select id, username, password, role from user where username=? and password=?

　　不管输入什么参数，打印出的SQL都是这样的。这是因为 MyBatis启用了预编译功能，在SQL执行前，会先将上面的SQL发送给数据库进行编译；执行时，直接使用编译好的SQL，替换占位符“?”就可以了。因为SQL注入只能对编译过程起作用，所以这样的方式就很好地避免了SQL注入的问题。

　　【底层实现原理】MyBatis是如何做到SQL预编译的呢？其实在框架底层，是JDBC中的PreparedStatement类在起作用，PreparedStatement是我们很熟悉的Statement的子类，它的对象包含了编译好的SQL语句。这种“准备好”的方式不仅能提高安全性，而且在多次执行同一个SQL时，能够提高效率。原因是SQL已编译好，再次执行时无需再编译

source ： 什么是日志？ - 名字到底要多长 - 博客园 (cnblogs.com)

日志用来记录用户操作、系统运行状态等，是一个系统的重要组成部分。日志分类：日志从功能来说，可分为诊断日志、统计日志、审计日志。

诊断日志， 典型的有：

• 请求入口和出口
• 外部服务调用和返回
• 资源消耗操作: 如读写文件等
• 容错行为： 如云硬盘的副本修复操作
• 程序异常： 如数据库无法连接
• 后台操作：定期执行删除的线程
• 启动、关闭、配置加载

统计日志：

• 用户访问统计：用户IP、上传下载的数据量，请求耗时等
• 计费日志（如记录用户使用的网络资源或磁盘占用，格式较为严格，便于统计）

审计日志：

• 管理操作

对于简单的系统，可以将所有的日志输出到同一个日志文件中，并通过不同的关键字进行区分。而对于复杂的系统，将不同需求的日志输出到不同的日志文件中是必要的，通过对不同类型的文件采用不同的日志格式（例如对于计费日志可以直接输出为Json格式），可以方便接入其他的子系统。

日志中记录什么

实践中常见到的无用的日志有：1）能够放在一条日志里的东西，放在多条日志中输出；2）预期会发生且能够被正常处理的异常，打印出一堆无用的堆栈；3）开发人员在开发过程中为了调试方便而加入的“临时”日志。

在实践中经常发生日志不够的情况，1）请求出错时不能通过日志直接来定位问题，而需要开发人员再临时增加日志并要求请求的发送者重新发送同样的请求才能定位问题；2）无法确定服务中的后台任务是否按照期望执行；3）无法确定服务的内存数据结构的状态；4）无法确定服务的异常处理逻辑（如重试）是否正确执行；5）无法确定服务启动时配置是否正确加载；

source ： 消息队列MQ_tsundere_ning的博客-CSDN博客