ALL父查询中的每个结果大于子查询结果集中的每一个值,则为真。
//查询表table_name1中age字段大于table_name2所有的age的数据 select * from table_name1 where age(select age from table_name2)
ANY父查询中的每个结果大于子查询结果集中的任意一个值,则为真。
//查询表table_name1中age字段大于table_name2中任意一个age的值 select * from table_name1 where age(select age from table_name2)
SOME作用大致与ANY相同,日常使用中看做一致即可。
SQL优化时我们提到,很多时候用 exists 代替 in 是一个好的选择,这里明确说一下exists的用法和作用。
语法:
SELECT column_name(s) FROM table_name WHERE EXISTS (SELECT column_name FROM table_name WHERE condition);
意义:
EXISTS 运算符用于判断查询子句是否有记录,如果有一条或多条记录存在返回 True,否则返回 False。
注意:
EXISTS子句中不允许有COMPUTE子句和INTO关键字
EXISTS中column_name实际上是不影响查询结果的,所以为了更快地检索,建议只写一个主键字段,另外EXISTS中where子句要和外面的表有逻辑关系,否则要不查询所有数据,要不一行数据都不出现。
用法:
在子查询中使用NULL仍然返回结果集
select * from TableIn where exists(select null) select * from TableIn//与上方效果相同
比较使用EXISTS和IN的查询的使用,返回结果相同
select * from TableIn where exists(select BID from TableEx where BNAME=TableIn.ANAME) select * from TableIn where ANAME in(select BNAME from TableEx比较使用EXISTS和)
比较使用 EXISTS 和 ANY 的查询。注意两个查询返回相同的结果。
select * from TableIn where exists(select BID from TableEx where BNAME=TableIn.ANAME) select * from TableIn where ANAME=ANY(select BNAME from TableEx)
作用:
mysql union操作符用于连接两个以上的select语句的结果组合到一个结果集合中。
语法:
SELECT column_name1, column_name2, ... column_namen FROM tables [WHERE conditions] UNION [ALL | DISTINCT] SELECT column_name1, column_name2, ... column_namen FROM tables [WHERE conditions];
注意:
使用时select查询的column_name字段数量和内容要一致
DISTINCT: 默认值,可不写,删除结果集中重复的数据。默认情况下 UNION 操作符已经删除了重复数据,所以 DISTINCT 修饰符对结果没啥影响。
ALL:可选,返回所有结果集,包含重复数据。
SELECT 列名称 FROM 表名称 UNION SELECT 列名称 FROM 表名称 ORDER BY 列名称; SELECT 列名称 FROM 表名称 UNION ALL SELECT 列名称 FROM 表名称 ORDER BY 列名称;
MySQL版本必须大于5.7.6,小于这个版本只支持英文全文索引,不支持中文,需要利用分词器把中文段落预处理拆分成单词,然后存入数据库。
前置条件需要用到FULLTEXT索引,所以数据表引擎必须使用MyISAM,建立全文检索的字段类型必须是char,varchar,text。
对于大的数据库,将数据装载到一个没有 FULLTEXT 索引的表中,然后再使用 ALTER TABLE (或 CREATE INDEX) 创建索引,这将是非常快的。而将数据装载到一个已经有 FULLTEXT 索引的表中,是非常慢的。
MySQL 中使用全局变量ngram_token_size来配置ngram中n的大小,它的取值范围是1到10,默认值是2。通常ngram_token_size设置为要查询的单词的最小字数。如果需要搜索单字,就要把ngram_token_size设置为1。在默认值是2的情况下,搜索单字是得不到任何结果的。因为中文单词最少是两个汉字,推荐使用默认值2。
索引全文本数据时,短词被忽略且从索引中排除。短词定义为那些具有3个或3个以下字符的词(如果需要,这个数目可以更改)。
许多词出现的频率很高,搜索它们没有用处(返回太多的结果)。因此,MySQL规定了一条50%规则,如果一个词出现在50%以上的行中,则将它作为一个非用词忽略。50%规则不用于IN BOOLEAN MODE。
如果表中的行数少于3行,则全文本搜索不返回结果(因为每个词或者不出现,或者至少出现在50%的行中)。
忽略词中的单引号。例如,don't索引为dont。
不具有词分隔符(包括日语和汉语)的语言不能恰当地返回全文本搜索结果。
SELECT note_text FROM table_name WHERE Match(note_text) Against('search_text')
Match()指定被搜索的列,Against()指定要使用的搜索表达式。
使用完整的 Match() 说明传递给 Match() 的值必须与FULLTEXT()定义中的相同。如果指定多个列,则必须列出它们(而且次序正确)。
搜索不区分大小写 除非使用BINARY方式,否则全文本搜索不区分大小写。
select note_text,match(note_text) AGAINST('search_text')AS rank FROM table_name;
Match()和Against()用来建立一个计算列(别名为rank),此列包含全文本搜索计算出的等级值。等级由MySQL根据行中词的数目、唯一词的数目、整个索引中词的总数以及包含该词的行的数目计算出来。不包含词search_text的行等级为0(因此不被前一例子中WHERE子句选择)。确实包含词search_text的每行都有一个等级值,文本中词靠前的行的等级值比词靠后的行的等级值高。
排序多个搜索项,如果指定多个搜索项,则包含多数匹配词的那些行将具有比包含较少词(或仅有一个匹配)的那些行高的等级值。
SELECT note_text FROM table_name Match(note_text) Against('search_text' WITH QUERY EXPANSION);
例如:
SELECT note_text FROM productnotes Match(note_text) Against('anvils' WITH QUERY EXPANSION);
结果:
Multiple customer returns,anvils failing to drop fast enough orfal7ing backwards on purchaser. Recommend that customer considersusing heavier anvils. Customer complaint: Sticks not individually wrapped,too easy tomistakenly detonate all at once. Recommend individua7 wrapping.Customer complaint: Not heavy enough to generate flying starsaround headof victim. If being purchased for dropping,recommendANVO2 or ANVO3 instead. Please note that no returns wil7 be accepted if safe opened usingexplosives . Customer complaint: rabbit has been able to detect trap,foodapparently less effective now . Customer complaint: Circular hole in safe floor can apparently beeasily cut with handsaw. Matches not included,recommend purchase of matches or detonator(item DTNTR).
这次返回了7行。第一行包含词anvils,因此等级最高。第二行与anvils无关,但因为它包含第一行中的两个词(customer和recommend),所以也被检索出来。第3行也包含这两个相同的词,但它们在文本中的位置更靠后且分开得更远,因此也包含这一行,但等级为第三。第三行确实也没有涉及anvils(按它们的产品名)。
正如所见,查询扩展极大地增加了返回的行数,但这样做也增加了你实际上并不想要的行的数目。
SELECT note_text FROM table_name WHERE Match(note_text) Against('表达式' IN BOOLEAN MODE)
例如:匹配note_text中带有shx的,且不包含big的。
SELECT note_text FROM table_name WHERE Match(note_text) Against('+shx -big' IN BOOLEAN MODE)
布 尔 操 作 符 | 说 明 |
+ | 包含,词必须存在 |
- | 排除,词必须不出现 |
> | 包含,而且增加等级值 |
< | 包含,且减少等级值 |
() | 把词组成子表达式(允许这些子表达式作为一个组被包含、排除、排列等) |
~ | 取消一个词的排序值 |
* | 词尾的通配符 |
"" | 定义一个短语(与单个词的列表不一样,它匹配整个短语以便包含或排除这个短语) |
MySQL索引的建立对于MySQL的高效运行是很重要的,索引可以大大提高MySQL的检索速度。
拿汉语字典的目录页(索引)打比方,我们可以按拼音、笔画、偏旁部首等排序的目录(索引)快速查找到需要的字。
索引分单列索引和组合索引:
单列索引,即一个索引只包含单个列,一个表可以有多个单列索引,但这不是组合索引。
组合索引,即一个索引包含多个列。
创建索引时,你需要确保该索引是应用在 SQL 查询语句的条件(一般作为 WHERE 子句的条件)。
实际上,索引也是一张表,该表保存了主键与索引字段,并指向实体表的记录。
上面都在说使用索引的好处,但过多的使用索引将会造成滥用。
因此索引也会有它的缺点:虽然索引大大提高了查询速度,同时却会降低更新表的速度,如对表进行INSERT、UPDATE和DELETE。因为更新表时,MySQL不仅要保存数据,还要保存一下索引文件。
建立索引会占用磁盘空间的索引文件。
普通索引是mysql中最基本的索引类型,它没有任何限制,唯一任务就是加快系统对数据的访问速度。
普通索引允许在定义索引的列中插入重复值和空值
创建普通索引时,通常使用的关键字是index或key
SQL语句添加方式:
CREATE INDEX indexName ON table_name (column_name)//新建 ALTER table tableName ADD INDEX indexName(columnName)//修改表结构添加普通索引
唯一索引与普通索引类似,不同的是创建唯一性索引的目的不是为了提高访问速度,而是为了避免数据出现重复。
唯一索引列的值必须唯一,允许有空值。
如果是组合索引,则列值的组合必须唯一。
创建唯一索引通常使用 unique 关键字。
SQL语句添加方式:
CREATE UNIQUE INDEX indexName ON table_name (column_name(length)) //新建 ALTER table mytable ADD UNIQUE [indexName] (column_name(length))//修改表结构添加唯一索引
全文索引主要用来查找文本中的关键字,只能在 CHAR、VARCHAR 或 TEXT 类型的列上创建。
在 MySQL 中只有 MyISAM 存储引擎支持全文索引
全文索引允许在索引列中插入重复值和空值。
不过对于大容量的数据表,生成全文索引非常消耗时间和硬盘空间。
创建全文索引使用 FULLTEXT 关键字。
CREATE FULLTEXT INDEX index_name ON table_name(column_name);
空间索引是对空间数据类型的字段建立的索引,使用 SPATIAL 关键字进行扩展。
创建空间索引的列必须将其声明为 NOT NULL,空间索引只能在存储引擎为 MyISAM 的表中创建。
空间索引主要用于地理空间数据类型 GEOMETRY。对于初学者来说,这类索引很少会用到。
SQL语句添加方式:
CREATE SPATIAL INDEX index_name ON table_name(column_name);
顾名思义,主键索引就是专门为主键字段创建的索引,也属于索引的一种。
主键索引是一种特殊的唯一索引,不允许值重复或者值为空。
创建主键索引通常使用 PRIMARY KEY 关键字。不能使用 CREATE INDEX 语句创建主键索引。
索引在逻辑上分为以上 5 类,但在实际使用中,索引通常被创建成单列索引和组合索引。
单列索引就是索引只包含原表的一个列。在表中的单个字段上创建索引,单列索引只根据该字段进行索引。
单列索引可以是普通索引,也可以是唯一性索引,还可以是全文索引。
只要保证该索引只对应一个字段即可。
组合索引也称为复合索引或多列索引。
相对于单列索引来说,组合索引是将原表的多个列共同组成一个索引。多列索引是在表的多个字段上创建一个索引。
该索引指向创建时对应的多个字段,可以通过这几个字段进行查询。
但是,只有查询条件中使用了这些字段中第一个字段时,索引才会被使用。
例如:在表中的 id、name 和 sex 字段上建立一个多列索引,那么,只有查询条件使用了 id 字段时,该索引才会被使用。
一个表可以有多个单列索引,但这些索引不是组合索引。
一个组合索引实质上为表的查询提供了多个索引,以此来加快查询速度。
比如:在一个表中创建了一个组合索引(c1,c2,c3),在实际查询中,系统用来实际加速的索引有三个:单个索引(c1)、双列索引(c1,c2)和多列索引(c1,c2,c3)。
对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。
应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描。如:
select id from t where num is null
可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:
select id from t where num=0
应尽量避免在 where 子句中使用!=或<>操作符,否则引擎将放弃使用索引而进行全表扫描。
应尽量避免在 where 子句中使用or 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描。如:
select id from t where num=10 or num=20
可以这样查询:
select id from t where num=10 union all select id from t where num=20
in 和 not in 也要慎用,否则会导致全表扫描。如:
select id from t where num in(1,2,3)
对于连续的数值,能用 between 就不要用 in 了:
select id from t where num between 1 and 3
下面的查询也将导致全表扫描:
select id from t where name like ‘%李%’
若要提高效率,可以考虑全文检索。
如果在 where 子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。
如下面语句将进行全表扫描:
select id from t where num=@num
可以改为强制查询使用索引:
select id from t with(index(索引名)) where num=@num
应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如:
select id from t where num/2=100
应改为:
select id from t where num=100*2
应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。如:
select id from t where substring(name,1,3)=’abc’
name以abc开头的id应改为:
select id from t where name like ‘abc%’
不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。
在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使用,并且应尽可能的让字段顺序与索引顺序相一致。
不要写一些没有意义的查询,如需要生成一个空表结构:
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集,但是会消耗系统资源的,应改成这样:
create table #t(…)
很多时候用 exists 代替 in 是一个好的选择:
select num from a where num in(select num from b)
用下面的语句替换:
select num from a where exists(select 1 from b where num=a.num)
并不是所有索引对查询都有效,SQL是根据表中数据来进行查询优化的,当索引列有大量数据重复时,SQL查询可能不会去利用索引,如一表中有字段sex,male、female几乎各一半,那么即使在sex上建了索引也对查询效率起不了作用。
索引并不是越多越好,索引固然可以提高相应的 select 的效率,但同时也降低了 insert 及 update 的效率,因为 insert 或 update 时有可能会重建索引,所以怎样建索引需要慎重考虑,视具体情况而定。一个表的索引数最好不要超过6个,若太多则应考虑一些不常使用到的列上建的索引是否有必要。
应尽可能的避免更新 clustered 索引数据列,因为 clustered 索引数据列的顺序就是表记录的物理存储顺序,一旦该列值改变将导致整个表记录的顺序的调整,会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列,那么需要考虑是否应将该索引建为 clustered 索引。
尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。
尽可能的使用 char/nchar代替varchar/nvarchar ,因为首先固定长度的char/nchar比可变长度的varchar/nvarchar 存储空间小,可以节省存储空间,其次对于查询来说,在一个相对较小的字段内搜索效率显然要高些。
任何地方查询都不要使用 select * from t ,用具体的字段列表代替“*”,不要返回用不到的任何字段。
尽量使用表变量来代替临时表。如果表变量包含大量数据,请注意索引非常有限(只有主键索引)。
避免频繁创建和删除临时表,以减少系统表资源的消耗。
临时表并不是不可使用,适当地使用它们可以使某些例程更有效,例如,当需要重复引用大型表或常用表中的某个数据集时。但是,对于一次性事件,最好使用导出表。
在新建临时表时,如果一次性插入数据量很大,那么可以使用 select into 代替 create table,避免造成大量 log ,以提高速度;如果数据量不大,为了缓和系统表的资源,应先create table,然后insert。
如果使用到了临时表,在存储过程的最后务必将所有的临时表显式删除,先 truncate table ,然后 drop table ,这样可以避免系统表的较长时间锁定。
尽量避免使用游标,因为游标的效率较差,如果游标操作的数据超过1万行,那么就应该考虑改写。
使用基于游标的方法或临时表方法之前,应先寻找基于集的解决方案来解决问题,基于集的方法通常更有效。
与临时表一样,游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法,尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时 间允许,基于游标的方法和基于集的方法都可以尝试一下,看哪一种方法的效果更好。
在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ,在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送DONE_IN_PROC 消息。
尽量避免大事务操作,提高系统并发能力。
尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理。
在js代码中写入debugger,回到浏览器F12打开检查窗口,触发js后从debugger开始调试,按F10执行一行代码,并在代码后面显示数值。
使用 debugger 语句类似于在代码中设置断点。
在一些类似于文章博客的内容中,会用到模糊搜索检索多个字段,对于检索后的结果排序可能并不满意。
例如:
在CSDN搜索一篇博文,在输入关键字后会检索文章的标题,内容,分类,标签等内容,但是检索的排序结果可能不太理想,比如想优先显示标题中带有此关键字的文章,不管是按主键或者时间排序都是不行的。
下面我就简单的说明一下遇到这种问题的几种解决办法:
利用LOCATE函数(MySQL数据库),按照匹配度进行排序。
locate(subStr,string) 函数返回subStr在string中出现的位置,返回结果大于0代表着subStr出现的位置(从开始就存在则为1,即如果string中存在subStr最小值为1),如果等于0则说明subStr不存在。
检索`name`和`memo`字段中存在'shx'的信息,并优先显示`name`字段中存在'shx'信息并且出现位置靠前的数据:
SELECT `name`,`memo`,locate('shx',`name`) as `order_name` FROM `cs_user` where `name` like "%shx%" or `memo` like "%shx%" order by `order_name` desc
检索`name`和`memo`字段中存在'shx'的信息,并优先显示`name`字段中存在'shx'信息并且出现位置靠前的数据,如果`name`字段中'shx'信息出现的位置相同或者都不存在,即`order_name`为0时,则优先显示`memo`字段中存在'shx'信息并且出现位置靠前的数据:
SELECT `name`,`memo`,locate('shx',`name`) as `order_name`,locate('shx',`memo`) as `order_memo` FROM `cs_user`where `name` like "%shx%" or `memo` like "%shx%" order by `order_name` desc,`order_memo` desc
等待更新
简单来说就是,攻击者通过一些技术手段欺骗用户通过浏览器去访问一个,自己已经认证过(登陆过,留下过登录验证信息)的网站,进行一系列操作(例如:发邮件,发消息,甚至财产操作和转账),所以被访问的网站会认为是真正的用户操作而去运行。
简单的身份验证只能保证请求发自某个用户的浏览器,却不能保证请求是用户自愿发出的。
假设:
假如把1000元钱转账给shx的链接为:
https://www.bank.com/withdraw?amount=1000&for=shx
那么,一个恶意攻击者top可以在另外一个网站上设置如下链接:
https://www.bank.com/withdraw?amount=1000&for=top
如果用户登陆过账号不久,登录信息尚未过期,并且被攻击者骗取打开此链接,那么shx就有可能会损失1000元钱。
①检查Referer字段:
HTTP头中有一个Referer字段,这个字段用以标明请求来源于哪个地址。在处理敏感数据请求时,通过此字段获取发送请求的网址,并传递给服务器端,这时候服务器就能识别出是否为恶意访问。
这种办法简单易行,工作量低,仅需要在关键访问处增加一步校验。但这种办法也有其局限性,因其完全依赖浏览器发送正确的Referer字段。虽然http协议对此字段的内容有明确的规定,但并无法保证来访的浏览器的具体实现,亦无法保证浏览器没有安全漏洞影响到此字段。并且也存在攻击者攻击某些浏览器,篡改其Referer字段的可能。
②添加校验token:
由于CSRF的本质是利用存储在浏览器中的验证数据欺骗用户去访问攻击者设置的地址,只要用户提供的验证数据不存储在浏览器中,并且攻击者无法伪造验证数据作为效验,那么攻击者就无法运行CSRF攻击。
所以这种验证数据一般是由服务器生成,将其放在请求的返回值中,其内容是一个伪随机码,当客户端提交数据时,将这个伪随机码一并提交上去做校验。
当用户正常访问时,客户端能接受并返回这个随机码,而通过CSRF传来的欺骗性攻击中,攻击者无法事先得知或伪造这个伪随机码,服务器就会因为token的值为空或者错误,拒绝这个可疑请求。
③在 HTTP 头中自定义属性并验证:
这种方法本质也是使用 token 并进行验证,和上一种方法不同的是,这里并不是把 token 以参数的形式置于 HTTP 请求之中,而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类,可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性,并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便,同时,通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏,也不用担心 token 会透过 Referer 泄露到其他网站中去。
然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新,并非所有的请求都适合用这个类来发起,而且通过该类请求得到的页面不能被浏览器所记录下,从而进行前进,后退,刷新,收藏等操作,给用户带来不便。另外,对于没有进行 CSRF 防护的遗留系统来说,要采用这种方法来进行防护,要把所有请求都改为 XMLHttpRequest 请求,这样几乎是要重写整个网站,这代价无疑是不能接受的。
XSS攻击通常是指利用网页开发时留下的漏洞,通过巧妙的方法注入恶意指令代码到网页,使用户加载并执行攻击者恶意制造的网页程序。
HTML是一种超文本标记语言,通过将一些字符特殊地对待来区别文本和标记,当HTML标签引入了一段JavaScript脚本时,这些脚本程序就将会在用户浏览器中执行。所以,当这些特殊字符不能被动态页面检查或检查出现失误时,就将会产生XSS漏洞。
①由于XSS攻击在用户当前使用的应用程序中执行,用户将会看到与其有关的个性化信息,如账户信息或“欢迎回来”消息,克隆的Web站点不会显示个性化信息。
②通常,在钓鱼攻击中使用的克隆Web站点一经发现,就会立即被关闭。
③许多浏览器与安全防护软件产品都内置钓鱼攻击过滤器,可阻止用户访问恶意的克隆站点。
④如果客户访问一个克隆的Web网银站点,银行一般不承担责任。但是,如果攻击者通过银行应用程序中的XSS漏洞攻击了银行客户,则银行将不能简单地推卸责任。
①持久型跨站:最直接的危害类型,跨站代码存储在服务器(数据库)。
②非持久型跨站:反射型跨站脚本漏洞,最普遍的类型。用户访问服务器-跨站链接-返回跨站代码。
③DOM跨站(DOM XSS):DOM(document object model文档对象模型),客户端脚本处理逻辑导致的安全问题。
基于DOM的XSS漏洞是指受害者端的网页脚本在修改本地页面DOM环境时未进行合理的处置,而使得攻击脚本被执行。在整个攻击过程中,服务器响应的页面并没有发生变化,引起客户端脚本执行结果差异的原因是对本地DOM的恶意篡改利用。
①盗用cookie,获取敏感信息。
②利用植入Flash,通过crossdomain权限设置进一步获取更高权限;或者利用Java等得到类似的操作。
③利用iframe、frame、XMLHttpRequest或上述Flash等方式,以(被攻击)用户的身份执行一些管理动作,或执行一些一般的如发微博、加好友、发私信等操作。
④利用可被攻击的域受到其他域信任的特点,以受信任来源的身份请求一些平时不允许的操作,如进行不当的投票活动。
⑤在访问量极大的一些页面上的XSS可以攻击一些小型网站,实现DDoS攻击的效果。
①不信任用户提交的任何内容,对所有用户提交内容进行可靠的输入验证,包括对URL、查询关键字、HTTP头、REFER、POST数据等,仅接受指定长度范围内、采用适当格式、采用所预期的字符的内容提交,对其他的一律过滤。尽量采用POST而非GET提交表单;对“<”,“>”,“;”,“””等字符做过滤;任何内容输出到页面之前都必须加以en-code,避免不小心把htmltag显示出来。
②实现Session 标记(session tokens)、CAPTCHA(验证码)系统或者HTTP引用头检查,以防功能被第三方网站所执行,对于用户提交信息的中的img等link,检查是否有重定向回本站、不是真的图片等可疑操作。
③cookie 防盗。避免直接在cookie中泄露用户隐私,例如email、密码,等等;通过使cookie和系统IP绑定来降低cookie泄露后的危险。这样攻击者得到的cookie没有实际价值,很难拿来直接进行重放攻击。
④确认接收的内容被妥善地规范化,仅包含最小的、安全的Tag(没有JavaScript),去掉任何对远程内容的引用(尤其是样式表和JavaScript),使用HTTPonly的cookie。
mysqladmin --version 验证mysql
mysql -h主机地址 -u用户名 -p 连接mysql
show engines 查看数据库支持的引擎
show variables like '%storage_engine%' 查看当前使用的数据库引擎
MySQL每个数据库都会在data目录下生成一个目录,里面有*.frm、*.myi、*.myd和*.opt文件。
*.frm--表定义,是描述表结构的文件。
*.MYD--"D"数据信息文件,是表的数据文件。
*.MYI--"I"索引信息文件,是表数据文件中任何索引的数据树。
*.opt--记录数据库选项,数据库的字符集。
增:返回添加记录的id,删和修返回影响的条数,查返回查询出来的结果集。
MySQL数据库版本:
5.X:
5.0-5.1:早期产品的延续,升级维护
5.2-5.3:不常用
5.4-5.X:MySQL整合了三方公司的新存储引擎,以前的版本都是mysql自己单干。(现在主要是用5.5和5.7)
连接层:提供与客户端连接的服务
服务层:1.提供各种接口。2.提供SQL优化器:MySQL QUery Optimizer
引擎层:提供了各种存储数据的方式(InnoDB MyISAM)
存储层:存储数据
InnoDb:事务有限,适合高并发操作;行锁
MyISAM:性能优先