This is going to be highly dependent on the context.
I'll start off by saying that "checked into production" doesn't mean anything. Is that "checked into an integration branch in source control" or "checked into the main branch of source control" or "deployed to production"? All of those can be very different things, all of which could be viable for a team's Definition of Done.
There are a few baseline rules to start with. First, the Definition of Done needs to be achievable. Each unit of work should meet the Definition of Done within the Sprint. The overall Increment needs to meet the Definition of Done by the end of the Sprint. Second, any work necessary to achieve the Sprint Goal needs to meet the Definition of Done by the end of the Sprint, which is at the Sprint Review and Sprint Retrospective. Third, the team should work to make the Definition of Done more stringent over time.
In a case where I was working with teams on a complex hardware/software system, the Definition of Done was that the work was integrated into an integration-ready build and available for the system integration team. This implied designed, developed, tested with unit and integration tests, peer reviewed, tested against a simulator or emulator, and ready to be installed on physical hardware in an integration setting for additional testing.
In another case where I was working with teams on a web application, the Definition of Done was that the work was merged into the development branch in source control. The design and development was complete, testing was complete, and the independent verification team understands the changes and the required testing at a system level.
In both of these cases, any work necessary to achieve the Sprint Goal had to meet the Definition of Done prior to the Sprint Review. It doesn't say when the Sprint Goal had to be achieved, though. Sometimes, the Sprint Goal was achieved days before the Sprint Review, and an Increment was ready to go.
The use of Continuous Integration / Continuous Delivery / Continuous Deployment is also a factor here. In order to take advantage of CI/CD, you need to be integrating frequently, perhaps even merging work-in-progress to upstream branches and using feature flags and keystone interfaces to control the environments where the work is visible and how stakeholders can interact with it to provide feedback.