"Determine User Login" is PHP so judging the process is correct? Querying data inventory cookies every time

"Determine user Login" is this the correct process for judging php? Querying data inventory cookies every time
I'll do it myself. PHP Determines whether a user is logged in:

Process
1 First determine if there is no cookie (' uid ') && cookie (' uid ') if no bounce detection
2 If there is, the connection database queries the record for that UID, and if not changed, jumps out of loop detection and logs off all user cookies
3 If there is, detect the cookie (' upwd ') = = MD5 ($rs [Pwd].cookie (' salt ')), if not equal, prompt password change requires re-login
4 if equal, detection cookie (' email ') = = MD5 ($rs [email]), if not equal, prompt mailbox changes, need to log back in
5 if equal = = is correct, the user is the currently logged on user.

But!
Problem
1 each time to connect the database, reduce database query is the key to user optimization, if every time to go to the database query, really will affect performance.
2 How to optimize the best, this login to determine whether the process is wrong.

"Another way of thinking."
1 store to session, save $uid, $uname, $lastactive (last response time) to session.
2 If there is a session (' UID ') && session (' uname ') to detect time ()-$lastactive > 3600, then connect to the database query (as above the cookie judgment), Otherwise direct use (Session storage location php.ini default configuration location)

Problem
1 if it is stored in the session, is it affected by high concurrency?


------Solution--------------------
When using the second scenario, you are concerned about high concurrency.
So does the first scenario take the case of high concurrency?

In your first scenario, the user's password and email are placed in a cookie, which is always running around the network, do you think it's safe?

The database should be generalized
Although file system-based relational databases (SQL) may be slightly slower, they all provide memory-based memory tables
Besides, the database has another branch: memory-based NoSQL
So the extra overhead of database queries can be negligible

The process for determining whether a user is logged in is:
If the cookie (' uid ') does not exist, the Goto requires login processing
Otherwise, query the database to check if the UID was last logged in the same location as this time:
The same confirms
Different to send a prompt, conditional forwarding request login Processing
------Solution--------------------
That's what I'm doing.
1. The user login, connect the database to determine whether the success, such as the success of the user ID, user name, etc. need to use the information of judgment, write session and Cookies,cookies set a time (such as 1 days to the week, this login to the user to choose), in addition, I make a json_encode of the data stored in the cookies, and then encrypt the processing.
For example {"UID": 1, "username": "Fdipzone"} is encrypted into a reversible string.

2. When the user visits, there are several situations
1. Determine if the session exists
2. Determine if the session exists-------------------to determine whether the cookie is successful
3. Determine if the session exists--------------------------to determine if the cookie is successful.
4. Determine if the session exists--------to determine if the cookie exists----Skip to the login page
------Solution--------------------
Correct it, please.
When the session expires, the cookie is written to the session. In this location, the database is checked to see if the user is banned from logging in.
The session has its own expiration time, so every time the database check interval is the session life cycle.

Determine if a session exists------------------to determine if the cookie is successfully decrypted. Check to see if login is forbidden ----write cookies into session->

Determine if a session exists------------------to determine if the cookie is successfully decrypted. check whether to disable login----clear user cookies-> jump to notification page

