Coded unit test, database and Dependency Injection

I have following questions related to the code unit tests for the classes which are pretty much integrated with the database logic. E.g. My class method calls another class that executes a database query or stored procedure.

If I don't want to to involve real database during unit testing what are the options?

Many people use the interface driven approach in which I will have to declare an interface. Then during unit testing, I will have to provide an implementation of the interface which does not work with the real database.

I know that in real world I will not have various implementations of the same interface. So the concrete class is OK for me. But is it advisable to declare an interface just for the sake of unit testing?

If we declare an interface and write unit tests using it, I may want to decide an implementation during test execution, then we may have to start thinking of the IoC containers to inject concrete class at runtime. Now this makes application unnecessarily complex.

How to deal with this?