Mysql Internals on restart We have a huge database and many procedures loaded onto it to cater reports and some of them are called every 5 min throughout the day.

Database is performing pretty well otherwise, but if I do not restart mysql once daily, queries which used to take few milliseconds to execute takes minutes and even hours to finish. 
Even mysqldump (selective dumping of data based on timestamp columns) which normally completes in 15 minutes is taking 3-4 hours to complete if mysql restart is not done on daily basis.

Can anyone please help me understand what does mysql do internally on restart.
We use lots of temporary tables in our procedures. Could these be causing contention?
I am quoting from the official MySQL 5.7 documentation in my answer. This question has an evolving state and (hopefully) will contain as much information as possible.

mysqld, also known as MySQL Server, is the main program that does most of the work in a MySQL installation. MySQL Server manages access to the MySQL data directory that contains databases and tables. The data directory is also the default location for other information such as log files and status files.
When MySQL server starts, it listens for network connections from client programs and manages access to databases on behalf of those clients.

The mysqld program has a lot of options that can be specified at startup. A complete list of options can be retrieved when you run this command:

shell&gt; mysqld --verbose --help

The MySQL documentation recommends that:

When troubleshooting, it is usually best to run the MySQL server from the command prompt, rather than through mysqld_safe or as a Windows service

If you want to see what the mysqld service starts or touches during the start-up procedure, you can start mysqld directly at the command prompt with:
shell&gt; mysqld 

You might find information during the startup procedure, which are causing your performance issues.
If you are using the default innoDB configuration you will make use of the InnoDB Temporary Table Undo Logs which are part of the Temporary Tablespace which is initialised during the start-up process:

The temporary tablespace is recreated on each server start and receives a dynamically generated space ID, which helps avoid conflicts with existing space IDs.

Temporary table undo logs have restrictions:

Temporary table undo logs, introduced in MySQL 5.7.2, are used for temporary tables and related objects. This type of undo log is not a redo log, as temporary tables are not recovered during crash recovery and do not require redo logs. Temporary table undo logs are, however, used for rollback while the server is running. This special type of non-redo undo log benefits performance by avoiding redo logging I/O for temporary tables and related objects. Temporary table undo logs reside in the temporary tablespace. The default temporary tablespace file, ibtmp1, is located in the data directory by default and is always recreated on server startup. A user defined location for the temporary tablespace file can be specified by setting innodb_temp_data_file_path.
32 rollback segments are reserved for temporary table undo logs for transactions that modify temporary tables and related objects, which means that the maximum number of rollback segments available for data-modifying transactions that generate undo records is 96. With 96 available rollback segments, the limit on concurrent data-modifying transactions is 96K. For more information see Section 15.3, “InnoDB Multi-Versioning” and Section 15.8.8, “Limits on InnoDB Tables”.

You might be hitting an issue where the number of transactions creating temporary objects is above this 96K level of connections. Or you might be just generating too many temporary objects.
Restarting your MySQL instance will (according to the Temporary Tablespace documentation) clean up your temporary tablespace and all temporary tables locate therein:
The temporary tablespace is removed on normal shutdown or on an aborted initialization
Given the information provided, I would suggest you to check your temporary objects, because you might have a problem in your temporary tablespace.