> RAM : 48GB, buffer_pool: 32GB, log_buffer: 2GB, data-size ( innodb tables ): 12GB.
OK, That looks fine (12GB << 32GB << 48GB) -- you should not be doing much I/O. And defragmenting (OPTIMIZE TABLE) would have essentially no benefit.
> indexes: room_id_date (room_id,date_of_avail), room_id (room_id), hotel_id (hotel_id).
No PRIMARY KEY?? Probably (room_id,date_of_avail) should be the PK?? Or is (id) the PK, but you failed to list it?? (I would really prefer to see SHOW CREATE TABLE; it answers these and other questions!)
An InnoDB table works better with an explicit PK.
> deleting daily : procedure : start transaction, get the ids of past data, delete one by one row, commit.
Not enough specifics. Perhaps this will give you some ideas:
http://mysql.rjweb.org/doc.php/deletebig
See also INSERT ... ON DUPLICATE KEY UPDATE. That may be better than what sounds like INSERT, then DELETE.
> indexes: room_id_date (room_id,date_of_avail), room_id (room_id), hotel_id (hotel_id).
Any query that might want to use (room_id) can almost as efficiently use (room_id, date_of_avail), so DROP the shorter index. Since every index must be updated on every INSERT and DELETE, this will speed things up.
> we are planning to update the MySQL verion ( 5.5.40), Please suggest.
Good idea. It is not likely to help with the current problem, but it is good to upgrade.
I was hoping to see something in the InnoDB STATUS that matched something in the PROCESSLIST. Does the issue occur during the daily delete? If so, let's focus on it.