使用springsecurity使用,连mysql,同表名,可以查localhost的表,但是不可查云服务的表

你的位置：网站首页 >> 频道首页 >>数据库 >>使用springsecurity使用,连mysql,同表名,可以查localhost的表,但是不可查云服务的表

使用springsecurity使用,连mysql,同表名,可以查localhost的表,但是不可查云服务的表

来源：蜘蛛抓取(WebSpider) 时间：2018-10-03 02:09 标签： springsecurity使用

MySQL 临时表在我们需要保存一些临时数据时是非常有用的。临时表只在当前连接可见，当关闭连接时，MySQL会自动删除表并释放所有空间。

使用其他MySQL客户端程序连接MySQL数据库服务器来创建临时表，那么只有在关闭客户端程序时才会销毁临时表，当然也可以手动删除。

一、MySQL中的两种临时表

通过CREATE TEMPORARY TABLE 创建的临时表，这种临时表称为外部临时表。这种临时表只对当前用户可见，当前会话结束的时候，该临时表会自动关闭。这种临时表的命名与非临时表可以同名（同名后非临时表将对当前会话不可见，直到临时表被删除）。

　　　　内部临时表是一种特殊轻量级的临时表，用来进行性能优化。这种临时表会被MySQL自动创建并用来存储某些操作的中间结果。这些操作可能包括在优化阶段或者执行阶段。这种内部表对用户来说是不可见的，但是通过EXPLAIN或者SHOW 　　STATUS可以查看MYSQL是否使用了内部临时表用来帮助完成某个操作。内部临时表在SQL语句的优化过程中扮演着非常重要的角色， MySQL中的很多操作都要依赖于内部临时表来进行优化。但是使用内部临时表需要创建表以及中间数据的存取代价，所以用户在写SQL语句的时候应该尽量的去避免使用临时表。

　　内部临时表有两种类型：一种是HEAP临时表，这种临时表的所有数据都会存在内存中，对于这种表的操作不需要IO操作。另一种是OnDisk临时表，顾名思义，这种临时表会将数据存储在磁盘上。OnDisk临时表用来处理中间结果比较大的操作。如果HEAP临时表存储的数据大于MAX_HEAP_TABLE_SIZE（详情请参考MySQL手册中系统变量部分），HEAP临时表将会被自动转换成OnDisk临时表。OnDisk临时表在5.7中可以通过INTERNAL_TMP_DISK_STORAGE_ENGINE系统变量选择使用MyISAM引擎或者InnoDB引擎。

二、外部临时表的常见用法

外部临时表是通过CREATE TEMPORARY TABLE及DROP TABLE来操作的，但是SHOW TABLES命令显示数据表列表时，你将无法看到自己创建的临时表的。并且在退出当前会话后，临时表就会被自动销毁。当然也可以手动（DROP TABLE）销毁。

2.2、外部临时表使用时注意几点：

1、自己所用的数据库账号要有建立临时表的权限；

2、在同一条sql中，不能关联2次相同的临时表，不然，就会报如下错误；

3、临时表在建立连接时可见，关闭时会清除空间，删除临时表；

7、如果你为一个表声明了别名，当你指向这个表的时候，就必须使用这个别名。见《》

二、内部临时表的常见用法

　　如果用户在书写SQL语句的时候能够尽量少的使用内部临时表进行查询优化，将有效的提高查询执行的效率。

首先我们定义一个表t1，

下面所有的操作都是基于表t1进行举例的。

SQL_BUFFER_RESULT主要用来让MySQL尽早的释放表上的锁。因为如果数据量很大的话，需要较长时间将数据发送到客户端，通过将数据缓冲到临时表中可以有效的减少读锁对表的占用时间。SQL_BUFFER_RESULT见《》

如果我们查询系统表的话，系统表的数据将被存储到内部临时表中。

我们当前不能使用EXPLAIN来查看是否读取系统表数据需要利用到内部临时表，但是可以通过SHOW STATUS来查看是否利用到了内部临时表。

如果查询带有ORDER BY语句，并且不能被优化掉。下面几种情况会利用到内部临时表缓存中间数据，然后对中间数据进行排序。

2）ORDER BY的列不属于执行计划中第一个连接表的列。

3）如果ORDER BY的表达式是个复杂表达式。

那么什么样的ORDER BY表达式，MySQL认为是复杂表达式呢？

1))如果排序表达式是SP或者UDF。

为了简化执行计划，我们利用INDEX来优化GROUP BY语句。

4) 如果查询既带有ORDER BY同时也有GROUP BY语句，但是两个语句使用的列不相同。

同样为了简化执行计划，我们利用INDEX来优化GROUP BY语句。

如果查询带有GROUP BY语句，并且不能被优化掉。下面几种情况会利用到内部临时表缓存中间数据，然后对中间数据进行GROUP BY。

2) 如果GROUP BY的列不属于执行计划中的第一个连接表。

如果查询语句带有UNION，MySQL将利用内部临时表帮助UNION操作消除重复。

如果查询语句使用多表更新。
这里Explain不能看到内部临时表被利用，所以需要查看status。

如果聚集函数中包含如下函数，内部临时表也会被利用。

总之，上面列出了10种情况，MySQL将利用内部临时表进行中间结果缓存，如果数据量比较大的话，内部临时表将会把数据存储在磁盘上，这样显然会对性能有所影响。为了尽可能的减少性能损失，我们需要尽量避免上述情况的出现。

MySQL在以下几种情况会创建临时表：

4、表连接中，ORDER BY的列不是驱动表中的； 7、FROM中的子查询； 8、子查询或者semi-join时创建的表；

当然了，如果临时表中需要存储的数据量超过了上限（或中取其大者），这时候就需要生成基于磁盘的临时表了。

在以下几种情况下，会创建磁盘临时表：

2、在 GROUP BY 或者 DSTINCT 的列中有超过 512字符的字符类型列（或者超过 512字节的二进制类型列，在5.6.15之前只管是否超过512字节）； 3、在SELECT、UNION、UNION ALL查询中，存在最大长度超过512的列（对于字符串类型是512个字符，对于二进制类型则是512字节）；

TABLE 创建的临时表的引擎类型，在以前默认是MEMORY，不要把这二者混淆了。

一、定义数据结构（mysql）:

四、自定义的登陆页面：

users-by-username-query为根据用户名查找用户，系统通过传入的用户名查询当前用户的登录名，密码和是否被禁用这一状态。

authorities-by-username-query为根据用户名查找权限，系统通过传入的用户名查询当前用户已被授予的所有权限。

authentication-failure-url表示用户登陆失败时，跳转到哪个页面。当用户输入的登录名和密码不正确时，系统将再次跳转到/login.jsp，并添加一个error=true参数作为登陆失败的标示。

授权服务是基于Spring Security的，因此需要在项目中引入两个依赖

此时浏览器会让你输入用户名密码，这是因为 Spring Security 在默认情况下会对所有URL添加Basic Auth认证。默认的用户名为user, 密码是随机生成的，在控制台日志中可以看到。

画风虽然很简陋，但是基本功能都具备了。点击Authorize后，浏览器就会重定向到百度，并带上code参数：

拿到code以后，就可以调用

到此我们最最基本的授权服务就搭建完成了。然而，这仅仅是个demo，如果要在生产环境中使用，还需要做更多的工作

在上面的例子中，所有的token信息都是保存在内存中的，这显然无法在生产环境中使用(进程结束后所有token丢失, 用户需要重新授权)，因此我们需要将这些信息进行持久化操作。
把授权服务器中的数据存储到数据库中并不难，因为 Spring Cloud Security OAuth 已经为我们设计好了一套Schema和对应的DAO对象。但在使用之前，我们需要先对相关的类有一定的了解。

要想使用这些JDBC实现，首先要建表。框架为我们提前设计好了schema, 在github上：
在使用这套表结构之前要注意的是，对于MySQL来说，默认建表语句中主键是varchar(255)类型，在mysql中执行会报错，原因是mysql对varchar主键长度有限制。所以这里改成128即可。其次，语句中会有某些字段为LONGVARBINARY类型，它对应mysql的blob类型，也需要修改一下。

完成这些后，框架就会将中间产生的数据写到mysql中了。oauth_client_details是client表，可以直接在该表中添加记录来添加client:

Spring Security OAuth2有一个奇葩的设计，那就是它将与access_token相关的所有属于都封装到OAuth2AccessToken中，然后保存时会直接将该对象序列化成字节写入数据库。我们在资源服务器中想要直接读数据库来取出access_token来验证令牌的有效性，然而又不想引入Spring Security的相关依赖污染jar包。这时可以将Spring 通过JDK自带的反序列化机制来还原DefaultOAuth2AccessToken对象。这时就会遇到问题，即原来的OAuth2AccessToken所在包是以.XXXX开头的，这样在反序列化时，即使两个类的字段完全一样，但由于字节流中存储的类信息的全限定性名不同，也会导致反序列化失败

这样在反序列化时就不会报错了。原理并不复杂，其实就是在解析字节流时，将解析后应为.XXXXXX.DefaultOAuthToken从而达到”欺骗”的目的。在该场景下，我们就可以做到在资源提供方不引入 Spring Security 框架而只使用Spring Security OAuth2的授权服务。资源提供方直接读数据库来验证令牌的有效性，而不是向授权服务查询。

至此一个能在生产环境下使用的授权服务就搭建好了。其实我们在实际使用时应该适当定制JdbcTokenStore或ClientDetailsService来实适应业务需要，甚至可以直接从0开始实现接口，完全不用框架提供的实现。另外，Spring 直接将DefaultOAuth2AccessToken序列化成字节保存到数据库中的设计，我认为是非常不合理的。或许设计者的初衷是保密access_token，但是通过加密的方法也可以实现，完全不应该直接扔字节。不过通过定制TokenStore接口，我们可以使用自己的表结构而不拘泥于默认实现。