1、InnoDB与MyISAM数据库存储引擎有什么区别。
- MyISAM不支持事务，InnoDB是事务类型的存储引擎，当我们的表需要用到事务支持的时候，那肯定是不能选择MyISAM了
- MyISAM只支持表级锁，BDB支持页级锁和表级锁默认为页级锁，而InnoDB支持行级锁和表级锁默认为行级锁
- MyISAM引擎不支持外键，InnoDB支持外键
- MyISAM引擎的表在大量高并发的读写下会经常出现表损坏的情况
- 对于count()查询来说MyISAM更有优势
- InnoDB是为处理巨大数据量时的最大性能设计，它的CPU效率可能是任何其它基于磁盘的关系数据库引擎所不能匹敌的
- MyISAM支持全文索引（FULLTEXT），InnoDB不支持
- MyISAM引擎的表的查询、更新、插入的效率要比InnoDB高
2、InnoDB的索引使用了什么数据结构，与MyISAM使用的索引有什么区别。
InnoDB ：聚簇索引（行数据与键值（主键）紧凑地存储在一起）
InnoDB中表现为：B+树叶子节点的data用于存放行数据（包含主键值、其他列数据、回滚指针、事务id等），物理上索引数据与行数据都放在同一个文件中（.idb）
InnoDB 二级索引
二级索引，或者叫非聚簇索引；与聚簇索引最大的不同是：B+树的data存放的并不是行数据，而是主键值；
MyISAM 索引
与InnoDB不同，MyISAM并不使用聚簇索引，MyISAM的索引数据和行数据是分开的，物理上分别为.myi索引数据文件和.myd行数据文件（InnoDB 索引和行数据均在.idb文件中）
MyISAM中，主键索引和其他的一般索引在数据结构上并没有什么区别，B+树的data存放的均是数据行地址。
3、mysql为什么要使用B+树作为索引呢？
B+树的中间节点不保存数据，是纯索引,但是B树的中间节点是保存数据和索引的,相对来说,B+树磁盘页能容纳更多节点元素，更“矮胖”；
B+树查询必须查找到叶子节点，B树只要匹配到即可不用管元素位置，因此b+树查找更稳定（并不慢）；
对于范围查找来说，B+树只需遍历叶子节点链表即可，B树却需要重复地中序遍历,在项目中范围查找又很是常见的
增删文件（节点）时，效率更高，因为B+树的叶子节点包含所有关键字，并以有序的链表结构存储，这样可很好提高增删效率。
4、解释XSS 和 CSRF，它们之间有什么区别，以及如何防范。
XSS全称Cross Site Scripting，名为跨站脚本攻击，黑客将恶意脚本代码植入到页面中从而实现盗取用户信息等操作。
常见的攻击情景：
- 用户A访问安全网站B，然后用户C发现B网站存在XSS漏洞，此时用户C向A发送了一封邮件，里面有包含恶意脚本的URL地址（此URL地址还是网站B的地址，只是路径上有恶意脚本），当用户点击访问时，因为网站B中cookie含有用户的敏感信息，此时用户C就可以利用脚本在受信任的情况下获取用户A的cookie信息，以及进行一些恶意操作。这种攻击叫做反射性XSS
- 假设网站B是一个博客网站，恶意用户C在存在XSS漏洞的网站B发布了一篇文章，文章中存在一些恶意脚本，例如img标签、script标签等，这篇博客必然会存入数据库中，当其他用户访问该文章时恶意脚本就会执行，然后进行恶意操作。这种攻击方式叫做持久性XSS，将携带脚本的数据存入数据库，之后又由后台返回。
预防措施：
- 对输入、输出结果进行过滤和必要的转义
- 尽量使用post，使用get方式时对路径长度进行限制
- 使用httponly禁止黑客通过脚本获取用户cookie数据，但这样无法完全阻止xss攻击，因为发送http请求并不需要主动获取cookie
CSRF全称cross-site request forgery，名为跨站请求伪造，顾名思义就是黑客伪装成用户身份来执行一些非用户自愿的恶意以及非法操作
常见攻击情景：
用户A经常访问博客网站B，用户C发现网站B存在CSRF漏洞，想尽了各种办法勾引用户A访问了C写好的危险网站D，而此时用户A的cookie信息还没有失效，危险网站D中有向网站B求请求的非法操作，这样用户在不知情的情况下就***控了。
这个时候就会有一个疑问，浏览器本身有同源策略啊，为什么在网站D还可以请求网站B的api，要记住浏览器对img、iframe和script的src是没有同源限制的！所以黑客完全可以利用动态添加这些标签的方法来实现跨站请求。
预防措施：
1、验证码
2、tokenId令牌
3、判断请求的Referer是否正确
CSRF和XSS的区别：
1、CSRF需要登陆后操作，XSS不需要
2、CSRF是请求页面api来实现非法操作，XSS是向当前页面植入js脚本来修改页面内容。
京公网安备 11010502036488号