服务端 rbac 权限验证，是否有必要进行增加性能优化？

我不想用服务端里基于注解的权限验证框架，比如 Shiro 。所有的服务端 action 接口的权限配置都在后台管理界面进行配置

最简单的 rbac 权限验证，放在 sql 数据库就是 5 个表，用户表，用户角色关联表，角色表，角色菜单关联表，菜单表。而验证就是凭借用户 id 从用户角色表查到关联的 role，在从 role，查到关联的 menu 。一个 sql 语句经过 4 个表。

那么，服务端 rbac 权验证，是否有必要进行增加性能优化？比如减少权限验证的时间。

我目前就想到一个方式，利用面向对象语言的引用特性，当项目启动时，载入角色与权限的关联数据永驻到服务端内存中，用户登录之后，创建一个集合，然后往集合内添加永驻在内存里的用户所含的角色权限关联引用，并且集合与用户绑定在 session 里。每次权限验证，都将请求 path 和用户的权限引用集合与服务端永驻内存的权限缓存进行对比。不在查询数据库。唯一看得出的缺陷是实时更新角色与 role 对应的维护有点麻烦。除了这个还有其他的方式么？

现在增加了 app 端，app 端用认证的不是 session，还是 token 。这个情况下，app 端的权限验证如果要进行性能优化，那是用什么方式呢，把角色关联数据加密，并到 token 令牌里安全么？还是性能优化没有必要的，直接根据 userid 去调 jdbc，用各 sql 语句一梭子查到菜单表进行对比就行了？

各位搭建编写 web 服务端的时候，权限验证有没有想过性能优化？有的话，一般都是怎样的？